While making OSX homebrew packages for libdivecomputer and subsurface I've ran into trouble using my newly compiled libdivecomputer. I've tried both with 1.0.1 and the git head but the results are the same. Running the test program for vyper produces the following result:
[mba:~/Temp/libdivecomputer] $ examples/vyper /dev/tty.SLAB_USBtoUART DEVICE=/dev/tty.SLAB_USBtoUART, DELAY=500 suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:38: Error opening serial port. suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:71: Error opening serial port.
SUMMARY ------- test_dump_sdm: Input/output error test_dump_memory: Input/output error
... but running the test program downloaded from the webpage works:
[mba:~/Downloads] $ ./vyper /dev/tty.SLAB_USBtoUART DATETIME 2012-07-06T19:16:32Z (1341602192) REVISION 781f0db71f7a06591e819f7960dd5b504b4f16a0 DEVICE=/dev/tty.SLAB_USBtoUART, DELAY=500 suunto_vyper_device_open Configure: baudrate=2400, databits=8, parity=2, stopbits=1, flowcontrol=0 Timeout: value=1000 DTR: value=1 Sleep: value=100 Flush: queue=3, input=0, output=0 device_foreach [... data dump ...]
Any ideas on what might be causing this?
Regards, Christian
On 07/06/2012 09:47 PM, Christian Axelsson wrote:
While making OSX homebrew packages for libdivecomputer and subsurface I've ran into trouble using my newly compiled libdivecomputer. I've tried both with 1.0.1 and the git head but the results are the same. Running the test program for vyper produces the following result:
[mba:~/Temp/libdivecomputer] $ examples/vyper /dev/tty.SLAB_USBtoUART DEVICE=/dev/tty.SLAB_USBtoUART, DELAY=500 suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:38: Error opening serial port. suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:71: Error opening serial port. SUMMARY ------- test_dump_sdm: Input/output error test_dump_memory: Input/output error... but running the test program downloaded from the webpage works:
Any ideas on what might be causing this?
You are the second person reporting this problem this week.
I have absolutely no idea what is causing this. My setup for compiling the macosx test applications is probably very different from yours. I'm cross-compiling the macosx (and windows) binaries on linux. But on the other hand macdive is having no such problems, so it must be possible to get it working on macosx. Unfortunately I don't have a clue how.
Jef
Hi,
I stumbled on that error previously, and I think it might come from a casting issue.
In the file serial_posix.c, can you try replacing the first line of the function serial_set_status, which is : int action = (level ? TIOCMBIS : TIOCMBIC); by : unsigned long action = (level ? TIOCMBIS : TIOCMBIC);
I think it should not break the function for other OS, but it might be worth some more thorough testing...
Pascal
On 06 Jul 2012, at 22:23, Jef Driesen wrote:
On 07/06/2012 09:47 PM, Christian Axelsson wrote:
While making OSX homebrew packages for libdivecomputer and subsurface I've ran into trouble using my newly compiled libdivecomputer. I've tried both with 1.0.1 and the git head but the results are the same. Running the test program for vyper produces the following result:
[mba:~/Temp/libdivecomputer] $ examples/vyper /dev/tty.SLAB_USBtoUART DEVICE=/dev/tty.SLAB_USBtoUART, DELAY=500 suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:38: Error opening serial port. suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:71: Error opening serial port.
SUMMARY
test_dump_sdm: Input/output error test_dump_memory: Input/output error
... but running the test program downloaded from the webpage works:
Any ideas on what might be causing this?
You are the second person reporting this problem this week.
I have absolutely no idea what is causing this. My setup for compiling the macosx test applications is probably very different from yours. I'm cross-compiling the macosx (and windows) binaries on linux. But on the other hand macdive is having no such problems, so it must be possible to get it working on macosx. Unfortunately I don't have a clue how.
Jef
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On 07/06/2012 10:34 PM, Pascal Manchon wrote:
I stumbled on that error previously, and I think it might come from a casting issue.
In the file serial_posix.c, can you try replacing the first line of the function serial_set_status, which is : int action = (level ? TIOCMBIS : TIOCMBIC); by : unsigned long action = (level ? TIOCMBIS : TIOCMBIC);
I think it should not break the function for other OS, but it might be worth some more thorough testing...
On my macosx setup (and Henrik confirmed it on a real installation), these constants are defined as:
#define TIOCMBIC _IOW('t', 107, int) #define TIOCMBIS _IOW('t', 108, int) #define TIOCM_DTR 0002
So that seems to indicate they are int's not long's. My linux manpages also confirms int. And the macosx references I could find, tell me the same:
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManP...
Strange. Maybe there is some difference between 32bit and 64bit? My apps are 32bit, and I suspect a native build will be 64bit. Can anyone try to build a 32bit version on a native macosx?
Jef
On 06.07.12 22:34, Pascal Manchon wrote:
Hi,
I stumbled on that error previously, and I think it might come from a casting issue.
In the file serial_posix.c, can you try replacing the first line of the function serial_set_status, which is : int action = (level ? TIOCMBIS : TIOCMBIC); by : unsigned long action = (level ? TIOCMBIS : TIOCMBIC);
I think it should not break the function for other OS, but it might be worth some more thorough testing...
My HelO2 has one of its "I don't want to show Data Transfer in the display" issues right now and has to rest a bit. So can't test a working connection right now.
But your fix has indeed done something anyway, it seems to actually try to contact the computer now:
$ examples/vyper2 /dev/tty.usbserial-ST000001 ## Before the fix DEVICE=/dev/tty.usbserial-ST000001 suunto_vyper2_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper2.c:123: Failed to set the DTR line. suunto_vyper2_test.c:77: Error opening serial port. suunto_vyper2_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper2.c:123: Failed to set the DTR line. suunto_vyper2_test.c:37: Error opening serial port.
SUMMARY ------- test_dump_memory: Input/output error test_dump_sdm: Input/output error
$ vim src/serial_posix.c ## replacing int with unsigned long $ make make all-recursive [...] $ examples/vyper2 /dev/tty.usbserial-ST000001 DEVICE=/dev/tty.usbserial-ST000001 suunto_vyper2_device_open dc_device_version suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2_test.c:85: Cannot identify computer. suunto_vyper2_device_open dc_device_version suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2_test.c:45: Cannot identify computer.
SUMMARY ------- test_dump_memory: Timeout test_dump_sdm: Timeout
Henrik
Jef,
To follow your request, I just did 2 tries on compiling libdivecomputer on my native OSX 64bit environment :
First try without options (compiles for 64bit) : $ ./configure $ examples/vyper /dev/tty.usbserial-PtTFP8W4 DEVICE=/dev/tty.usbserial-PtTFP8W4, DELAY=500 suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:38: Error opening serial port. suunto_vyper_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper.c:145: Failed to set the DTR line. suunto_vyper_test.c:71: Error opening serial port.
Second try with : $ export CPPFLAGS=-m32 $ export LDFLAGS=-m32 $ ./configure --build=i686
and this seem indeed to work correctly (at least the computer starts dumping its memory)
What actually made me try the unsigned long type is the man page for ioctl : https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManP...
Pascal
On 06 Jul 2012, at 23:13, Henrik wrote:
On 06.07.12 22:34, Pascal Manchon wrote:
Hi,
I stumbled on that error previously, and I think it might come from a casting issue.
In the file serial_posix.c, can you try replacing the first line of the function serial_set_status, which is : int action = (level ? TIOCMBIS : TIOCMBIC); by : unsigned long action = (level ? TIOCMBIS : TIOCMBIC);
I think it should not break the function for other OS, but it might be worth some more thorough testing...
My HelO2 has one of its "I don't want to show Data Transfer in the display" issues right now and has to rest a bit. So can't test a working connection right now.
But your fix has indeed done something anyway, it seems to actually try to contact the computer now:
$ examples/vyper2 /dev/tty.usbserial-ST000001 ## Before the fix DEVICE=/dev/tty.usbserial-ST000001 suunto_vyper2_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper2.c:123: Failed to set the DTR line. suunto_vyper2_test.c:77: Error opening serial port. suunto_vyper2_device_open TRACE (serial_posix.c:684, ioctl): Inappropriate ioctl for device (25) suunto_vyper2.c:123: Failed to set the DTR line. suunto_vyper2_test.c:37: Error opening serial port.
SUMMARY
test_dump_memory: Input/output error test_dump_sdm: Input/output error
$ vim src/serial_posix.c ## replacing int with unsigned long $ make make all-recursive [...] $ examples/vyper2 /dev/tty.usbserial-ST000001 DEVICE=/dev/tty.usbserial-ST000001 suunto_vyper2_device_open dc_device_version suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2_test.c:85: Cannot identify computer. suunto_vyper2_device_open dc_device_version suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2.c:194: Failed to receive the answer. suunto_vyper2_test.c:45: Cannot identify computer.
SUMMARY
test_dump_memory: Timeout test_dump_sdm: Timeout
Henrik
On 07/06/2012 11:21 PM, Pascal Manchon wrote:
To follow your request, I just did 2 tries on compiling libdivecomputer on my native OSX 64bit environment :
First try without options (compiles for 64bit) :
$ ./configureSecond try with :
$ export CPPFLAGS=-m32 $ export LDFLAGS=-m32 $ ./configure --build=i686and this seem indeed to work correctly (at least the computer starts dumping its memory)
That's exactly what I suspected. On most 32bit unix systems long is 32bit, just like int. But on 64bit, long is 64bit, but int is 32bits. Thus on 32bit int and long are the same, but not on 64bit.
What actually made me try the unsigned long type is the man page for ioctl : https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManP...
I was a little to quick when looking up info. The page I referred to, documents the data type of the third ioctl parameter, not the second "request" parameter. The page you refer to clearly documents request being "unsigned long". Strange is that on my linux system the manpages says its "int", but the <sys/ioctl.h> has a prototype with "unsigned long int". Thus unsigned long should work fine for both. Might be a bug in the linux manpages.
I'm not seeing any problems on 64bit linux, but maybe the actual value fits into an int, and on macosx it does not? Can someone check the actual values for TIOCMBIC and TIOCMBIS on 32 and 64bit macosx (using unsigned long of course).
Found a detailed analysis of the problem here:
http://bugs.python.org/issue1471
Jef
On 07.07.12 10:59, Jef Driesen wrote:
I'm not seeing any problems on 64bit linux, but maybe the actual value fits into an int, and on macosx it does not? Can someone check the actual values for TIOCMBIC and TIOCMBIS on 32 and 64bit macosx (using unsigned long of course).
Is this the way to do it?
printf("%ld %ld\n", TIOCMBIS, TIOCMBIC);
In that case, I've got this for 32bit:
-2147191700 -2147191701
... and this for 64bit:
2147775596 2147775595
Henrik
On 07/07/2012 11:09 AM, Henrik wrote:
On 07.07.12 10:59, Jef Driesen wrote:
I'm not seeing any problems on 64bit linux, but maybe the actual value fits into an int, and on macosx it does not? Can someone check the actual values for TIOCMBIC and TIOCMBIS on 32 and 64bit macosx (using unsigned long of course).
Is this the way to do it?
printf("%ld %ld\n", TIOCMBIS, TIOCMBIC);In that case, I've got this for 32bit:
-2147191700 -2147191701... and this for 64bit:
2147775596 2147775595
I already see what's the problem. These are 32bit negative values, and thus have the sign bit (the highest bit) set. For example TIOCMBIS is 0x8004746c. When signed integers are casted to a type with more bits (e.g. 32bit to 64bit) sign extensions is done to preserve the negative value. For TIOCMBIS the result would be 0xffffffff8004746c. But when interpreted as an unsigned long (which is probably what is done inside the ioctl call), it's a very different number of course.
For 32bit no sign extension is done, so no problem. On linux, the numbers are much smaller (e.g. TIOCMBIS is 21526), and thus the sign bit isn't set, so no problem on 32 and 64bit.
Thus the solution will be to use an unsigned type for the action variable, rather than a signed type. Both unsigned int and unsigned long should work fine.
Jef
Actually, it looks like it comes from a cast from the defined TIOCMBIS/TIOCMBIC to signed int then back to unsigned long. The compiler believes we ask him to keep the integer value and not the bytes :
printf("%ld %ld\n", sizeof(int), sizeof(unsigned long));
4 8
printf("%lx %lx\n", TIOCMBIS, TIOCMBIC);
8004746c 8004746b
unsigned long a = TIOCMBIS; unsigned long b = TIOCMBIC; printf("%lx %lx\n", a, b);
8004746c 8004746b
int c = TIOCMBIS; int d = TIOCMBIC; printf("%x %x\n", c, d); printf("%lx %lx\n", (unsigned long)c, (unsigned long)d);
8004746c 8004746b ffffffff8004746c ffffffff8004746b
unsigned int e = TIOCMBIS; unsigned int f = TIOCMBIC; printf("%x %x\n", e, f); printf("%lx %lx\n", (unsigned long)e, (unsigned long)f);
8004746c 8004746b 8004746c 8004746b
Linux has much lower values (sticking to 2 bytes) for these constants (0x5416 and 0x5417), so this unwanted conversion should not happen in 64bit, so we should not have the same issue with a Linux 64bit.
Pascal
On 07 Jul 2012, at 11:09, Henrik wrote:
On 07.07.12 10:59, Jef Driesen wrote:
I'm not seeing any problems on 64bit linux, but maybe the actual value fits into an int, and on macosx it does not? Can someone check the actual values for TIOCMBIC and TIOCMBIS on 32 and 64bit macosx (using unsigned long of course).
Is this the way to do it?
printf("%ld %ld\n", TIOCMBIS, TIOCMBIC);
In that case, I've got this for 32bit:
-2147191700 -2147191701
... and this for 64bit:
2147775596 2147775595
Henrik
Hi,
This is now fixed on the stable release-0.1 branch.
Jef
On 07/07/2012 12:29 PM, Pascal Manchon wrote:
Actually, it looks like it comes from a cast from the defined TIOCMBIS/TIOCMBIC to signed int then back to unsigned long. The compiler believes we ask him to keep the integer value and not the bytes :
printf("%ld %ld\n", sizeof(int), sizeof(unsigned long)); >>>> 4 8 printf("%lx %lx\n", TIOCMBIS, TIOCMBIC); >>>> 8004746c 8004746b unsigned long a = TIOCMBIS; unsigned long b = TIOCMBIC; printf("%lx %lx\n", a, b); >>>> 8004746c 8004746b int c = TIOCMBIS; int d = TIOCMBIC; printf("%x %x\n", c, d); printf("%lx %lx\n", (unsigned long)c, (unsigned long)d); >>>> 8004746c 8004746b >>>> ffffffff8004746c ffffffff8004746b unsigned int e = TIOCMBIS; unsigned int f = TIOCMBIC; printf("%x %x\n", e, f); printf("%lx %lx\n", (unsigned long)e, (unsigned long)f); >>>> 8004746c 8004746b >>>> 8004746c 8004746bLinux has much lower values (sticking to 2 bytes) for these constants (0x5416 and 0x5417), so this unwanted conversion should not happen in 64bit, so we should not have the same issue with a Linux 64bit.
Pascal
On 07 Jul 2012, at 11:09, Henrik wrote:
On 07.07.12 10:59, Jef Driesen wrote:
I'm not seeing any problems on 64bit linux, but maybe the actual value fits into an int, and on macosx it does not? Can someone check the actual values for TIOCMBIC and TIOCMBIS on 32 and 64bit macosx (using unsigned long of course).
Is this the way to do it?
printf("%ld %ld\n", TIOCMBIS, TIOCMBIC);
In that case, I've got this for 32bit:
-2147191700 -2147191701
... and this for 64bit:
2147775596 2147775595
Henrik
On 06.07.12 23:13, Henrik wrote:
My HelO2 has one of its "I don't want to show Data Transfer in the display" issues right now and has to rest a bit. So can't test a working connection right now.
But your fix has indeed done something anyway, it seems to actually try to contact the computer now:
It seems to work when I build for i386 as well:
$ vim src/serial_posix.c ## Revert to the int version $ make clean Making clean in examples rm -f universal solution eon vyper vyper2 d9 sensus sensuspro sensusultra aladin memomouse atom2 veo250 vtpro nemo puck darwin iconhd ostc frog edy n2ition3 [...] $ make -arch i386 make all-recursive Making all in include [...] $ examples/vyper2 /dev/tty.usbserial-ST000001 DEVICE=/dev/tty.usbserial-ST000001 suunto_vyper2_device_open dc_device_version suunto_vyper2.c:194: Failed to receive the answer. [...]
Henrik
On 06.07.12 22:23, Jef Driesen wrote:?
You are the second person reporting this problem this week.
I have absolutely no idea what is causing this. My setup for compiling the macosx test applications is probably very different from yours. I'm cross-compiling the macosx (and windows) binaries on linux. But on the other hand macdive is having no such problems, so it must be possible to get it working on macosx. Unfortunately I don't have a clue how.
I'm the other guy. I tried using a different interface on /dev/tty.usbserial-ST000001 as well (the original Suunto cable), with the same result. Both cables/devices work in MacDive and with the precompiled versions.
Henrik
-
Christian Axelsson -
Henrik -
Jef Driesen -
Pascal Manchon