Exodriver update issues

[Mathieu C.]

Hi,

I just upgraded to the latest driver version. I used the OSX installer (http://labjack.com/support/linux-and-mac-os-x-drivers).

Unfortunately, I now have a few issues using the LabJack with that new driver. In ppc64, any call to LJUSB_BulkWrite will always return 0
as the number of bytes written. My code can communicate with the Labjack U3 device properly on intel 64 bits, but the same code doesn't work
on ppc64. I get errno = ETIMEDOUT whenever I try to write data to the labjack on ppc64.

On the intel side, my code works fine. It streams 2 analog channels and 1 digital channel. However, it sometimes crashes when I
close the device (LJUSB_CloseDevice).

Are those some known issues ? I've never encounter such issues with the previous version I had (0.92).

Thanks,

Mathieu

[LabJack Support]

Unfortunately, I now have a few issues using the LabJack with that new driver. In ppc64, any call to LJUSB_BulkWrite will always return 0
as the number of bytes written. My code can communicate with the Labjack U3 device properly on intel 64 bits, but the same code doesn't work
on ppc64. I get errno = ETIMEDOUT whenever I try to write data to the labjack on ppc64.

We cross-compiled the Exodriver for all four architectures, PPC and x86, 32- and 64-bit. We'll get access to our ppc64 machine and build an architecture-specific version for you, and we'll see if that helps.

On the intel side, my code works fine. It streams 2 analog channels and 1 digital channel. However, it sometimes crashes when I
close the device (LJUSB_CloseDevice).

We haven't experienced that. We'll try to reproduce it. Would you share your stream configuration?

[Mathieu C.]

We cross-compiled the Exodriver for all four architectures, PPC and x86, 32- and 64-bit. We'll get access to our ppc64 machine and build an architecture-specific version for you, and we'll see if that helps.

We used to have a similar issue with version 0.91, where it would not detect any device on ppc. It now detects the device, but fails to write any data to U3_PIPE_EP1_OUT.

We haven't experienced that. We'll try to reproduce it. Would you share your stream configuration?

It happened approximately once a day since we updated with the latest driver. It never happened with the previous version. Unfortunately, it is not something we can easily reproduce. I'll post the backtrace if we can reproduce. Here is the code we use to set our stream configuration:

sendBuffer[1] = 0xF8;
sendBuffer[2] = (uint8_t)(3 + (analogInputsNumber + 1));
sendBuffer[3] = 0x11;
sendBuffer[6] = (uint8_t)(analogInputsNumber + 1);
sendBuffer[7] = 25;
sendBuffer[8] = 0x00;
sendBuffer[9] = 0x08 | 0x03;
sendBuffer[10] = (uint8_t)((48e6 / 10e3) & 0x00FF);
sendBuffer[11] = (uint8_t)((48e6 / 10e3) / 256);
for (uint8_t idx = 0; idx < analogInputsNumber; idx++)
{
sendBuffer[12 + 2 * idx] = idx;
sendBuffer[13 + 2 * idx] = 31;
}
sendBuffer[12 + 2 * analogInputsNumber] = 193;
sendBuffer[13 + 2 * analogInputsNumber] = 193;

[LabJack Support]

We cross-compiled the Exodriver for all four architectures, PPC and x86, 32- and 64-bit. We'll get access to our ppc64 machine and build an architecture-specific version for you, and we'll see if that helps.

We used to have a similar issue with version 0.91, where it would not detect any device on ppc. It now detects the device, but fails to write any data to U3_PIPE_EP1_OUT.

I tested the Exodriver on our PPC 64-bit machine with all our U3 examples, and they all worked flawlessly. I used the installer and then to double-check I built a second copy of the Exodriver from the source with DEBUG set to 1. It's very easy:

CODE

# Download libusb from our site and build it
$ curl -O http://labjack.com/sites/default/files/2009/10/libusb-1.0.3.tar_.bz2
$ tar xvfj libusb-1.0.3.tar_.bz2
$ cd libusb-1.0.3/
$ ./configure
$ make
$ sudo make install
$ cd ..

# Download the Exodriver from GitHub, turn on debugging, and build it
# Visit http://github.com/labjack/exodriver if the link below doesn't work
$ curl -O http://download.github.com/labjack-exodriver-cc9d92c.tar.gz
$ tar xvfz labjack-exodriver-cc9d92c.tar.gz
$ cd labjack-exodriver-cc9d92c/liblabjackusb
# Set DEBUG to 1 on line 45
# http://github.com/labjack/exodriver/blob/master/liblabjackusb/labjackusb.c#L45
$ vi labjackusb.c
$ ln -s -f Makefile.MacOSX Makefile
$ make
$ sudo make install
$ cd ..

# Build the U3 examples
$ cd examples/U3/
$ make
$ ./u3ConfigU3

Would you mind running u3ConfigU3 with an Exodriver that has DEBUG on? You can either follow the steps above or use the attached ZIP file which has everything built. (You'll have to run "sudo make install" in the liblabjackusb directory to install the debug copy of the library.) If u3ConfigU3 doesn't work for you, then the debug output may be useful to us in determining the problem.

By the way, our PPC 64-bit machine is a PowerMac G5 (Dual 2 GHz, circa 2004) running Mac OS X 10.5.

It happened approximately once a day since we updated with the latest driver. It never happened with the previous version. Unfortunately, it is not something we can easily reproduce. I'll post the backtrace if we can reproduce. Here is the code we use to set our stream configuration:

sendBuffer[1] = 0xF8;
sendBuffer[2] = (uint8_t)(3 + (analogInputsNumber + 1));
sendBuffer[3] = 0x11;
sendBuffer[6] = (uint8_t)(analogInputsNumber + 1);
sendBuffer[7] = 25;
sendBuffer[8] = 0x00;
sendBuffer[9] = 0x08 | 0x03;
sendBuffer[10] = (uint8_t)((48e6 / 10e3) & 0x00FF);
sendBuffer[11] = (uint8_t)((48e6 / 10e3) / 256);
for (uint8_t idx = 0; idx < analogInputsNumber; idx++)
{
sendBuffer[12 + 2 * idx] = idx;
sendBuffer[13 + 2 * idx] = 31;
}
sendBuffer[12 + 2 * analogInputsNumber] = 193;
sendBuffer[13 + 2 * analogInputsNumber] = 193;

We haven't tested this yet, but we'll get back to you when we do.

Attached File(s)

 labjack_exodriver_cc9d92c_DEBUG.zip ( 257.75K ) Number of downloads: 3

 

[Mathieu C.]

I'll try the Debug version on ppc64 today.

It crashed again on intel once per day this week. Here is the backtrace we see:

#0 0x000000010374f8da in darwin_close ()
#1 0x000000010374a7b3 in do_close ()
#2 0x000000010374a90e in libusb_close ()
#3 0x000000010375b2a2 in LJUSB_CloseDevice ()

Thanks,
Mathieu

[LabJack Support]

I'll try the Debug version on ppc64 today.

Yes, please report back.

It crashed again on intel once per day this week. Here is the backtrace we see:

Is your program leaking memory? When you look at it in the Activity Monitor, does the entry in the Real Mem column keep getting bigger? We encountered that problem when we tried to reproduce your problem, and we're close to a fix.

[Mathieu C.]

I ran the version you sent me and it works fine except that I get the following error before
its starts streaming:

Errorcode #52 from StreamStop read.

Here is the result of u3Config with the debug flag on:

./u3ConfigU3
U3 Configuration Settings:
FirmwareVersion: 1.090
BootloaderVersion: 0.270
HardwareVersion: 1.300
SerialNumber: 320034577
ProductID: 3
LocalID: 1
FIOAnalog (FIO0-7): 1 1 1 1 0 0 1 1
FIODirection (FIO0-7): 0 0 0 0 0 0 0 0
FIOState (FIO0-7): 0 0 0 0 0 0 0 0
EIOAnalog (EIO0-7): 0 0 0 0 0 0 0 0
EIODirection (EIO0-7): 0 0 0 0 0 0 0 0
EIOState (EIO0-7): 0 0 0 0 0 0 0 0
CIODirection (CIO0-3): 0 0 0 0
CIOState (CIO0-3): 0 0 0 0
DAC1Enable: 0
DAC0 (in byte form): 0
DAC1 (in byte form): 0

U3 Hardware Version >= 1.21 Configuration Settings:
Hardware Variations: 18
U3b (bit 0): 0
U3c (bit 1): 1
High Voltage (bit 4): 1

U3 Hardware Version 1.30 Configuration Settings:
TimerCounter Clock Source: 2
TimerCounter Divisor: 0
Compatibility Options: 0
Disable Timer Counter Pin Offset Errors (bit 0): 0

I'll try to figure out what the problem is in our code.

By the way, our ppc is a Dual 1.8 GHz PowerPC G5
running 0S 10.5.8.
Our intel is a 2 x 2.66 GHz Dual-Core Intel Xeon running
10.6.2.

[Mathieu C.]

I ran the version you sent me and it works fine except that I get the following error before
its starts streaming:

Errorcode #52 from StreamStop read.

After further investigation, I realized that the successful test was in ppc 32 bits. I recompiled everything
to run the test using the DEBUG version in ppc 64 bits and here is the result:

banshee:U3 mathieu$ ./u3ConfigU3
LJUSB_OpenDevice: Found handle for product ID 3
LJUSB_recentKernel: sysname: Darwin.
LJUSB_recentKernel: returning true on Darwin.
LJUSB_isMinFirmware: LJUSB_isRecentKernel: true
LJUSB_OpenDevice: Returning handle
LJUSB_endpoint: productId = -1, Pipe = 1
LJUSB_BulkWrite: endpoint = 0x1
ConfigU3 error : write failed

I get the same problem as in my code, a write error...

Thanks,
Mathieu

[LabJack Support]

I ran the version you sent me and it works fine except that I get the following error before
its starts streaming:

Errorcode #52 from StreamStop read.

After further investigation, I realized that the successful test was in ppc 32 bits. I recompiled everything
to run the test using the DEBUG version in ppc 64 bits and here is the result:

banshee:U3 mathieu$ ./u3ConfigU3
LJUSB_OpenDevice: Found handle for product ID 3
LJUSB_recentKernel: sysname: Darwin.
LJUSB_recentKernel: returning true on Darwin.
LJUSB_isMinFirmware: LJUSB_isRecentKernel: true
LJUSB_OpenDevice: Returning handle
LJUSB_endpoint: productId = -1, Pipe = 1
LJUSB_BulkWrite: endpoint = 0x1
ConfigU3 error : write failed

I get the same problem as in my code, a write error...

Thanks,
Mathieu

So this output is after following our steps in post #4 above (Dec 2 2009, 10:29 AM)? If so, then those steps worked for our ppc64 machine and not yours. We'll have to look into that more closely.


We never heard back from you regarding this issue on your Intel machine:

(Mathieu C. @ Dec 4 2009, 09:04 AM)
It crashed again on intel once per day this week. Here is the backtrace we see:

Is your program leaking memory? When you look at it in the Activity Monitor, does the entry in the Real Mem column keep getting bigger? We encountered that problem when we tried to reproduce your problem, and we're close to a fix.

We've traced a memory leak to a problem with libusb, but we haven't perfected the fix yet. It would be nice to know if you're experiencing the memorly leak. Check the Activity Monitor.

[Mathieu C.]

So this output is after following our steps in post #4 above (Dec 2 2009, 10:29 AM)? If so, then those steps worked for our ppc64 machine and not yours. We'll have to look into that more closely.

I followed the steps you told me except that that line didn't seem to work properly:
curl -O http://download.github.com/labjack-exodriver-cc9d92c.tar.gz
I downloaded the driver from the web instead:
http://github.com/labjack/exodriver

I also modified the makefiles to add -arch ppc64, since the default was building in 32 bits.

It works fine if I build it in 32 bits, but fails to write if I set the architecture to ppc64. All other
architectures seem to work fine.

We've traced a memory leak to a problem with libusb, but we haven't perfected the fix yet. It would be nice to know if you're experiencing the memorly leak. Check the Activity Monitor.

I let it run for half an hour without any noticeable leak in intel 64 bits. However, I did reproduce the crash this morning closing the U3 device. Same backtrace as usual.

Thanks,

Mathieu

[LabJack Support]

I also modified the makefiles to add -arch ppc64, since the default was building in 32 bits.

It works fine if I build it in 32 bits, but fails to write if I set the architecture to ppc64. All other
architectures seem to work fine.

I'll go back to my PowerMac G5, make this change, and see if it recreates the problem.

[LabJack Support]

I also modified the makefiles to add -arch ppc64, since the default was building in 32 bits.

It works fine if I build it in 32 bits, but fails to write if I set the architecture to ppc64. All other
architectures seem to work fine.

I'll go back to my PowerMac G5, make this change, and see if it recreates the problem.

I replicated the error on my PowerMac G5. I traced the problem to a bug in libusb, but I haven't found the solution yet. One symptom of the problem, and possibly the root of the problem is in libusb/os/darwin_usb.c. This function:

CODE

static int op_handle_events(struct libusb_context *ctx, struct pollfd *fds, nfds_t nfds, int num_ready) {...}

has this sequence of lines:

CODE

      read (hpriv->fds[0], &itransfer, sizeof (itransfer));
      read (hpriv->fds[0], &kresult, sizeof (IOReturn));
      read (hpriv->fds[0], &io_size, sizeof (UInt32));

On my MacBook Pro (x86_64) and PowerMac G5 (ppc7400), io_size is correctly set to a non-zero value (e.g., 38 or 26 for ConfigU3). On PowerMac G5 (ppc64), it's set to zero.

I'll look into it further and report back.

[Mathieu C.]

I'll look into it further and report back.

Hi,

I was wondering if there was any progress on that issue?
Thanks,

Mathieu

[LabJack Support]

I'll look into it further and report back.

Hi,

I was wondering if there was any progress on that issue?
Thanks,

Mathieu

No, I'm afraid not, but I'll make another attempt at fixing it this weekend.

[LabJack Support]

I'll look into it further and report back.

Hi,

I was wondering if there was any progress on that issue?
Thanks,

Mathieu

No, I'm afraid not, but I'll make another attempt at fixing it this weekend.

OK, I have a fix. It requires a small change to libusb. Here is the change in patch form:

CODE

$ cat libusb-1.0.3.ppc64.patch
diff -Naur libusb-1.0.3/libusb/os/darwin_usb.c libusb-1.0.3.ppc64/libusb/os/darwin_usb.c
--- libusb-1.0.3/libusb/os/darwin_usb.c    2009-08-22 22:19:31.000000000 -0600
+++ libusb-1.0.3.ppc64/libusb/os/darwin_usb.c    2010-01-31 23:45:51.000000000 -0700
@@ -1275,15 +1275,17 @@
   struct libusb_transfer *transfer = __USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
   struct darwin_device_handle_priv *priv = (struct darwin_device_handle_priv *)transfer->dev_handle->os_priv;
   UInt32 message;
+  UInt32 io_size;

   _usbi_log (ITRANSFER_CTX (itransfer), LOG_LEVEL_INFO, "an async io operation has completed");

   /* send a completion message to the device's file descriptor */
   message = MESSAGE_ASYNC_IO_COMPLETE;
+  io_size = (UInt32) arg0;
   write (priv->fds[1], &message, sizeof (message));
   write (priv->fds[1], &itransfer, sizeof (itransfer));
   write (priv->fds[1], &result, sizeof (IOReturn));
-  write (priv->fds[1], &arg0, sizeof (UInt32));
+  write (priv->fds[1], &io_size, sizeof (UInt32));
}

static void darwin_bulk_callback (struct usbi_transfer *itransfer, kern_return_t result, UInt32 io_size) {

If you know how to use patch, save the above file to libusb-1.0.3.ppc64.patch, find a clean copy of 1.0.3, untar it, and run:

CODE

$ cd libusb-1.0.3/
$ patch -p1 < path/to/libusb-1.0.3.ppc64.patch
patching file libusb/os/darwin_usb.c

Then rebuild and reinstall libusb:

CODE

$ ./configure && make && sudo make install

After installing the patched version of libusb, all of the U3 examples work for me. Let me know if they work for you, or if you need help making the necessary changes to libusb/os/darwin_usb.c . Also let me know if you need a patch against a different version of libusb (1.0.3 was referenced above).

If the patch works for you, we can inquire about contributing it upstream to libusb.

[Mathieu C.]

After installing the patched version of libusb, all of the U3 examples work for me. Let me know if they work for you, or if you need help making the necessary changes to libusb/os/darwin_usb.c . Also let me know if you need a patch against a different version of libusb (1.0.3 was referenced above).

I applied the patch and it now works fine on all 3 architectures (i386, x86_64 and ppc64).

If the patch works for you, we can inquire about contributing it upstream to libusb.

Yes, it would be a good thing to contribute that patch to libusb.

Thanks!!

Mathieu