Ubuntu 9.10 x64 hanging (possible java issue ?)

[LT401Vette]

MegaTunix DOES use lock files, but not the semi-std one that some other comms programs use. (It probably should use the std one, but,at the time i didn't know the right info about it when i coded that feature. current MegaTunix creates its lock files in /tmp.)

You know, where you should use the standard lock files they sure have been the leading Linux PITA for people, I have been temped to compile the RXTX driver without them. Or like you did with them in a place most users have access to, I guess it could still get ugly if someone fires up a different app and starts accessing the port...

[djandruczyk]

MegaTunix DOES use lock files, but not the semi-std one that some other comms programs use. (It probably should use the std one, but,at the time i didn't know the right info about it when i coded that feature. current MegaTunix creates its lock files in /tmp.)

You know, where you should use the standard lock files they sure have been the leading Linux PITA for people, I have been temped to compile the RXTX driver without them. Or like you did with them in a place most users have access to, I guess it could still get ugly if someone fires up a different app and starts accessing the port...

The problem is that not all apps use a lock, so even if i were to put the lock in the right place, there's still the risk of an issue.

[LT401Vette]

Agreed. I think the whole lock file concept would work better if the "right" place was a place that uses had access to by default, or the distros gave rights by default. Otherwise as it is, there is a deterrent to using the "right" place and like you said, once apps don't the whole point is out the window from a cross application point.

[Quan-Time]

so the summary is.. how do i get TS workin ?

[LT401Vette]

I don't think you ever confirmed your user is in uucp?

[Quan-Time]

your right ! /etc/group for ubuntu.. what am i specifically looking for ?

Code: Select all

uucp:x:10:quantime

i ADDED quantime just then.. to no avail.. am i spose to reload it somehow ? i figured it would be auto... ideas ?

-----
EDIT
-----

OK.. it now loads.. BUT wont detect the USB dongle.. Cant select TTYUSB0 for some reason.. tunix still works fine.. Something about stale lock ? What did i do wrong ? James has

Code: Select all

uucp:x:14:uucp,jsm

maybe thats an issue ? should i do it to reflect his ?

[LT401Vette]

Ok, what is the file size of the serial so file in the lib subdir?
Are you starting it using the TunerStudio.sh file?
Are you starting from a trminal that is set to TunerStudio's install dir?

[Quan-Time]

Code: Select all

-rw-r--r-- 1 quantime quantime  30882 2005-09-23 17:01 libLinuxSerialParallel.so
-rw-r--r-- 1 quantime quantime 326432 2006-03-02 05:34 librxtxSerial.jnilib
-rw-r--r-- 1 quantime quantime 138573 2010-01-08 14:04 librxtxSerial.so

starting with

Code: Select all

sh TunerStudio.sh

yes im doing it in the TunerStudio installed directory.

[LT401Vette]

Hmm...

138573 2010-01-08 14:04 librxtxSerial.so

That looks like the 64 bit driver

Well we could fall to another option..
Install RXTX through your package manager.
Then try to start the app with this command:

java -jar TunerStudioMS.jar

I'm not sure what is up. There are quite a few people running on the 64 bit Linux, so it should work as it is?

[mariob]

Hi,

i have TunerStudio on my 64-Bit-Debian since several months. Everything runs fine in the 32bit-chroot-jail, but if i try to run it in full 64-bit-mode i get hangups or errors pointing on the rxtx topic. If i change the serial-port to an invalid value in the ini-file it starts up fine (without any serial connection). I will try to find rxtx in the debian repositories and report what happens...

For me the solution with a 32-bit-chroot-jail is acceptable as i need it for other applications too. The additional ~100MB of diskspace shouldn't be a real problem for a machine modern enough to run 64Bits

Regarding the java-version i tried at least 1.6.0_15 to 1.6.0_17 without any noticable differences.

MegaLogViewer is running fine and it felt at least 20x faster than on my 32-Bit Notebook when doing VE-Analyze on a logfile of around 7 hours

Regards, Mario

[LT401Vette]

Now that is interesting... Maybe there is a problem with RXTX on 64 bit, at least with the way I have RXTX setup? I don't actually have a 64 bit Linux here to try it out on, maybe I need to remedy that. I think the 64 bit installs I have seen working were AMD processors. I don't know if that makes a difference here.

Mario, if you are analyzing 7 hour log files and are using speed density, give this beta a shot:
http://www.efianalytics.com/MegaLogViewer/beta/

That goes 15 times faster on a 20 minute log and the bigger the log the better the improvement as the current MLV slows down and takes more memory as it goes through the log, this one doesn't. I'll bet you get at least a 25-30 x speed improvement. The results will be identical.

[Quan-Time]

RXTX is installed, and still getting the same error

Code: Select all

TunerStudio$ java -jar TunerStudioMS.jar 
Jar Name:TunerStudioMS.jar
Experimental:  JNI_OnLoad called.
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyUSB0
RXTX Error:  Unable to 					remove stale lock file: /var/lock/LCK..ttyUSB0
[code]

any other options ?

[LT401Vette]

I did a quick search on rxtx and ubuntu 64 bit.

I found quite a few people having problems, and 1 person that claimed to get it working..
They claimed the beta 2.2 driver fixed it?

Try replacing your [TunerStudioInstallDir]/lib/librxtxSerial.so
with this one:

http://www.efianalytics.com/TunerStudio ... linux-gnu/

Then cross your fingers

[djandruczyk]

RXTX is installed, and still getting the same error

Code: Select all

TunerStudio$ java -jar TunerStudioMS.jar 
Jar Name:TunerStudioMS.jar
Experimental:  JNI_OnLoad called.
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyUSB0
RXTX Error:  Unable to 					remove stale lock file: /var/lock/LCK..ttyUSB0

any other options ?

do this:

Code: Select all

ls -la /var/lock
ls -la /var/lock/LCK..ttyUSB0

I suspect you may have ran some other serial app before under "sudo" which will create the lockfile as root, and then that app died/crashed leaving the lockfile around.

If there's a file there, run

Code: Select all

sudo rm -f /var/lock/LCK.ttyUSB0

I've verified this behavior is possible, via running minicom as root, then forcefully killing it from another shell, it leaves the lockfile there (owned as root), then trying to run minicon as a regular user fails which is hte same behavior your having with tunerstudio, so I suspect you have a stale lockfile owned as root that a regular user can't remove:

Code: Select all

dave@shrapnel:~$ minicom                             
Lockfile is stale. Overriding it..                   
Cannot create lockfile. Sorry.
dave@shrapnel:~$ 

[mariob]

I gave rxtx in version 2.2 a try and it worked correctly on my machine. (something is wrong with the link, i used the file from here: rxtx.qbang.org... ) From my experience at work i know about differences between AMD and Intel regarding task-switches under heavy parallel load. In combination with gcc and -O3 this can lead to uninteded behaviour, which can only be seen on one of both architectures. (and often but not always has its causes in missing semaphores) I don't think we will see big differences here, as the serial communication should be far away from multithreading...

I can also see these errors about stale lock-files when i hit Communications->Settings while i am connected to the MS. They don't occur when i just start TunerStudio and i can't find anything left in /var/lock/ when i close TunerStudio. (the files appear as they should when running TS)

As Phil told us, the beta-version of MLV runs VE Analyze much faster than the stable version with standard memory-settings. On the other hand i could really see a huge difference between my Notebook (1GB of RAM, MLV may get a half of it) and the bigger machine using 64 bits (where MLV was allowed to consume 2GB alone). This seemed much more than just the difference in the raw computing power to me.

[Quan-Time]

tried DJs idea, it was able to load, and in "communications" i had a lot more things show up. Soon as i clicked on port settings, flicked it to TTYUSB0, instantly dumped out again. Tried also "auto detect ECU" and same thing. Auto dumps out, and creates a lock file.

ill try that new file later.. got a few things to take care of, so give me a day or two..

Cheers everyone for the help.

[Quan-Time]

whats the best way to install / use that rxtx update ? ive yet to make it work.. ideas ?

[LT401Vette]

It may be worth trying the latest 64 bit tar onmy site. I put the newer driver in that.

[Quan-Time]

Code: Select all

quantime@allenkey:~/TunerStudio$ sh TunerStudio.sh
Jar Name:TunerStudioMS.jar
RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists
quantime@allenkey:~/TunerStudio$ ls /var/lock/
quantime@allenkey:~/TunerStudio$ 

OK.. i DID detect the firmware, only once.. Now for some reason it wont detect again / talk to it.. It doesnt crash anymore, so thats always a bonus.
When it worked, this is what i had

Code: Select all

quantime@allenkey:~/TunerStudio$ sh TunerStudio.sh 
Jar Name:TunerStudioMS.jar
RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..OM1: File exists
RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..OM1: File exists
quantime@allenkey:~/TunerStudio$ ls /var/lock/
LCK..OM1

So with that LCK..OM1 file, i was able to get a firmware version, but then it gave the lock error. Once i deleted it, ive not been able to detect it since. Ideas ?
I feel that we are working in the right direction tho..

-----
EDIT
-----
all workin sweet now. cheers heaps. twas my fault ! i didnt select the correct baud rate.. oops. it was defaulting to 9600, soon as i selected the correct speed, worked fine.. Maybe make the default different ?

Also, is there a way to edit the spark tables in a table format, rather than the 3d spinny view thing ?. Id like to just see the X - Y axis graph.. split into cells. Is that an option ? i cant find it.
Anyway. cheers heaps for your help.. Its been appreciated.