OSX - occasional error requiring unplug/replug

[ghost]

Running through the example, the first run working fine but thrown error in the next run. After that running fine again then thrown error again, and the same pattern for the next run.

Here the output of cpp-tutorial-2-streams when error:

rs::error was thrown when calling rs_create_context(api_version:4): libusb_bulk_transfer(...) returned LIBUSB_ERROR_TIMEOUT

Here the output of cpp-tutorial-2-streams when ok:

There are 1 connected RealSense devices.

Using device 0, an Intel RealSense F200
Serial number: 01FFFFFF9150096210
Firmware version: 2.60.0.0

I running it in MacBook Air 13" mid 2012

Version of libusb is 1.0.20 installed using homebrew.

I track down the error was thrown in this code of execute_usb_command (f200-private.cpp):

        // read
        if (in && inSize)
        {
            uint8_t buf[IVCAM_MONITOR_MAX_BUFFER_SIZE];

            errno = 0;

HERE----->            bulk_transfer(device, IVCAM_MONITOR_ENDPOINT_IN, buf, sizeof(buf), &outXfer, 1000);
            if (outXfer < (int)sizeof(uint32_t)) throw std::runtime_error("incomplete bulk usb transfer");

            op = *(uint32_t *)buf;
            if (outXfer > (int)inSize) throw std::runtime_error("bulk transfer failed - user buffer too small");
            inSize = outXfer;
            memcpy(in, buf, inSize);
        }

I've used the latest commit (a6df778)

The back of F200 still warm even after the application exit (i guess maybe the firmware still working in some loop). But the led is off, and there are no switching sound.

Have tried the hack version of the driver in here
https://github.com/mcguire-steve/libuvc
No issue like this happening. So i think it's not about libusb.

I think when the driver asking some data from the firmware. It stuck and not shutting down, even after the application exit.

[ddiakopoulos]

Thanks for the report! We've countered this several times in the past but we've never been able to find a reproducible test case. The bulk_transfer failure on the next run is just a symptom that the firmware is in some busy state after an unsuccessful shutdown. We've seen this on F200, R200, and SR300.

My running theory is that there's something funky with the timeout code in libusb/libuvc on OSX. Several other people have reported issues to this effect (also saying that the usb stack might fix this in 10.11?! - libuvc/libuvc#31). If this happens on >=50% of the runs of your app, we'd love to see the code so we can build a reproducible test case.

[ghost]

Thanks for the response. Still not yet investigating the libuvc. If there are anymore hint please free to notify me in here. Maybe i can fix it myself ;)

[ddiakopoulos]

If this is a blocking issue for you, check out the newly added code to reset devices in the dev branch. It might be a suitable workaround while we hunt down the root cause.

[ddiakopoulos]

@blackerpaper did you make any progress on this?

[ghost]

I still stuck. I have hunch it's about the interface of IVCAM_MONITOR. But still not succeeded.

[ddiakopoulos]

As I said above, the bulk_transfer in the ivcam monitor is a symptom, not the actual issue. I'm certain the system didn't release/shutdown the interfaces on the previous run of the camera. Until we have a hard reproducible test case, we won't be able to make any progress on this from our end.

[d235j]

Is this still an issue in Mac OS 10.11.4? Apple fixed many USB stack problems that caused similar issues with other software. (If you are running 10.10.x or earlier you should not be affected by those specific bugs.)

[ghost]

I use 10.11.3, maybe that's the problem. Unfortunately, my update stuck, can't update to 10.11.4, don't know why. I'll try to update it. If succeed i'll report again in here.

[d235j]

@blackerpaper if you're have problems updating, download the Combo Update from Apple's website and apply that — it's more likely to work.

[ddiakopoulos]

I used to be able to replicate with an R200, but I am on my home PC with 10.11.2 and I can't get it to throw the error.

[ghost]

Thanks @ddiakopoulos @d235j.

After updating into 10.11.4 this old bug have been vanished.

Conclusion:
10.10.x -> Should be OK
10.11.2 -> OK
10.11.3 -> Bug
10.11.4 -> OK

It seems the bug lay on the osx usb driver.