Your depth camera streams for a few seconds, the image freezes, and the capture call throws a frame timeout. Moments later the device is gone from lsusb. Underneath, dmesg holds uvcvideo: Non-zero status (-71) in video completion handler twice, plus a scatter of unknown-pixelformat lines. This guide walks the fault the way a bench debug does. You sort the three messages apart, read the completion code the host controller returned, then isolate port, cable, hub and host until one part is left. You finish with a committed verdict — power, cable, link speed, host, or the camera itself — and a bandwidth and power budget that predicts the drop before it happens.
Sort the three symptoms before you touch anything
The pixelformat lines are noise. They are warnings from the V4L2 core while an application enumerates FourCC depth formats the stock kernel does not name, and they print on links that stream for hours. The decoder for those codes is in V4L2 unknown pixelformat warnings in dmesg: FourCC decoded; read it once, then ignore the lines.
The events that matter come in order. First the freeze with a frame-timeout report from the capture call: frames stopped arriving. Then -71 in the completion handler: the controller ended in-flight transfers with an error as the device left the bus. A camera that never appears at all is a different fault with its own path — start from USB detection troubleshooting for stereo depth cameras on Ubuntu — but a camera that enumerates, streams and then drops is a link fault.
One command splits software from physics. Run v4l2-ctl --list-formats-ext -d /dev/video0, then again on /dev/video1 and /dev/video2: a three-node depth camera spreads depth, infrared and colour across separate nodes. If every node still lists its formats after the warnings appear, enumeration and permissions are proven good. The fault is physical — work the isolation path below.
What -71 actually is
-71 is EPROTO, the kernel's protocol-error status. uvcvideo prints the line when the host controller completes a video transfer with an error instead of a frame. That means the SuperSpeed link broke the protocol at the wire level: corrupted packets, a lane that dropped, or a device that lost power mid-transfer.
Two consequences follow. The fault sits below your vision software, below device permissions and below the UVC driver — re-patching a kernel module that already compiled and loaded changes nothing here. And -71 only appears when streams were being read at the moment of the drop. A camera that dies while idle fails without it, so treat its absence as no all-clear.
When the device has already left lsusb, camera disappears after capture crash: diagnose USB recovery covers getting the host stable again without a reboot.
The codes you will actually see
| dmesg status | errno | What the controller reported | First move |
|---|---|---|---|
| -71 | EPROTO | protocol error on the link | cable, then power, then port |
| -104 | ECONNRESET | device reset the connection mid-stream | power delivery, then the unit |
| -110 | ETIMEDOUT | no answer before the timeout | link stayed up: bandwidth, then the camera |
| -75, -84 | EOVERFLOW, EILSEQ | babble or illegal byte sequence: bit errors on the wire | replace the cable, reroute away from electrical noise |
| -108, -19 | ESHUTDOWN, ENODEV | the device left the bus | it already dropped: start at power |
The first three dominate on depth cameras. -71 alongside a freeze is a physical link failing under load. That sets the isolation order that follows: power, cable, link speed, host, unit.
Worked example: three VGA streams on one USB 3 port
The case: a compact stereo depth camera streaming depth, infrared and colour, each 640 x 480 pixels at 30 fps — the default format set for this camera class — bus-powered from a single USB 3 connection. The inputs are the camera's own defaults: 16-bit depth and YUYV colour are both 2 bytes per pixel. The power numbers are the USB specification's: 5 V at 900 mA (4.5 W) on a compliant SuperSpeed port, 5 V at 500 mA (2.5 W) on USB 2.0.
Per stream: 640 x 480 = 307,200 pixels; x 2 bytes = 614,400 bytes per frame; x 30 fps = 18,432,000 bytes/s, about 18.4 MB/s or 147 Mbps. Three streams: 3 x 18.4 MB/s = 55.3 MB/s, about 442 Mbps.
Against the bus: USB 2.0 high-speed moves at most 3 x 1024 bytes of isochronous video per 125 us microframe — 3072 x 8,000 = 24,576,000 bytes/s, about 24.6 MB/s. The 55.3 MB/s load is 2.25 times that ceiling, so a high-speed link cannot carry it, and the first symptom is a frame timeout. SuperSpeed runs a 5 Gbps line rate, 4 Gbps after encoding — 500 MB/s theoretical, around 400 MB/s delivered in practice — so 55.3 MB/s is roughly 14 percent of the link and fits with seven-fold headroom.
The decisions these numbers give you: more than about 24 MB/s of combined streams must hold a SuperSpeed link with no USB 2.0 element anywhere in the path. And a camera whose data-sheet draw is above about 4 W — within 10 percent of the 4.5 W port budget — runs from a self-powered hub.
Cause 1: the port cannot feed the camera
This is the most likely cause when the camera runs for seconds and dies exactly as the streams start, because current peaks at stream start. Front-panel headers, bus-powered hubs, ports shared with disks and long thin cables all shave the 4.5 W budget.
The test: move the camera to a rear port on the motherboard backplane, alone, with nothing else on that root port. Then repeat behind a self-powered USB 3 hub, which feeds the camera from its own adapter and leaves the host port carrying data only.
Decision: if drops continue on the rear port but stop behind the powered hub, that is a power verdict — run the camera powered permanently. The bus arithmetic for several cameras is in multiple USB cameras on one host: bandwidth and power budget, and the same starvation explains a depth camera black image on weak ports.
Cause 2: the cable fails at SuperSpeed
-71, -75 and -84 are the wire-error codes. A 5 m cable, an extension adapter, a retractable lead or a worn connector will pass USB 2.0 and fail SuperSpeed. At 5 Gbps the signalling leaves no margin for a marginal pair.
The test: one certified USB 3 cable, 2 m or shorter for the isolation run, no adapters in line, any locking screws or studs engaged, routed away from motor drives and switching supplies. Keep a known-good camera data cable on the bench for exactly this step:
The LS-CBL-0219 is a 3 m USB3.0 camera cable built for high-flex drag-chain use, so it survives being coiled and uncoiled between tests. For how far you can push a permanent run once the camera is stable, see USB cable length limits for 3D cameras; when the errors track one specific cable route, USB camera signal integrity: diagnosing OTG port image errors narrows it.
Cause 3: the link fell back to USB 2.0
Check the connect line in dmesg: new SuperSpeed USB device is what you want; new high-speed USB device means the whole path negotiated down. The worked example gives the consequence: 55.3 MB/s of streams against a 24.6 MB/s high-speed ceiling cannot work, whatever the driver does.
Three usual reasons: a USB 2.0 element in the path (cable, extension or hub port), a bent or fouled connector pin that drops a SuperSpeed lane pair, or a port that was never SuperSpeed — older front-panel wiring does this.
Sharing counts too: another camera or a disk on the same root port splits the same upstream link. The arithmetic for that split is in USB hub drops camera frame rate: budget the bandwidth first and depth and color stream timeouts: the USB bandwidth check. Test with the camera alone on its own controller.
Cause 4: the host controller or its power management
Two host-side faults reproduce this exact picture. Automatic suspend and USB autosuspend idle the device or pull power mid-stream, and resume leaves a UVC camera half-initialised; the next transfer then completes with an error. Exclude the camera from autosuspend in your distribution's power settings, and stop the machine suspending during capture.
The second is the controller itself: thin front-panel header wiring, a shared xhci port, or a controller mode setting in the board's setup utility. The clean test is a second host — a laptop on AC power with its own controller. An hour of stable streaming there convicts the first host. If the camera's vendor names a supported distribution for its SDK, use that host for the test. USB camera not enumerating: diagnose the host path walks the same host-side checks for a camera that never appears.
Cause 5: the camera itself
When the drop survives a rear port, one short certified cable, a powered hub, autosuspend off and a second host, the remaining variable is the unit. The fastest confirmation is a second camera of the same model on the same port and cable: if it streams for hours, stop debugging the link — the dropping unit is defective, and no setting will change that. Return it under warranty rather than spending another day on it.
If the fault lands here, the 3D sensors category carries direct replacements for the dead unit:
- Type
- Depth / ToF camera
- Type
- Stereo / structured light
The MV-DT01WMU is a Time-of-Flight depth camera, and the MV-DLS300P-04 is a laser galvanometer stereo camera. The latter is a laser product: respect the class label on the housing, never look into the apertures, and follow your site's laser-safety rules.
Why the udev script made things worse
A udev fix script changes device-node permissions — who is allowed to open /dev/video*. Your camera streamed frames, so permissions were already correct; the script had nothing to fix. By rewriting rules for the whole video subsystem it took the keyboard and mouse down with it. Undo the changes it made and reload the rules, then leave that layer alone: -71 is reported by host controller hardware, which no permission rule can reach.
The same logic clears the driver. The patched kernel module compiled, loaded, and the camera enumerated with all its interfaces — that is the software layer proven. Running the patch again re-proves it and changes no wire.
Checklist: prove the fix and keep it fixed
-
dmesgshowsnew SuperSpeed USB deviceat connect — anything less and every later test is invalid. -
v4l2-ctl --list-formats-extlists formats on every video node — depth, infrared and colour each have one. - One cable, 2 m or shorter, no extensions or adapters, for the isolation run.
- Rear motherboard port first, then a self-powered hub; nothing else shares that root port.
- Autosuspend off for the camera, and the machine does not suspend during capture.
- A 30-minute soak on all three streams before you call it fixed.
- A second host, and a second unit if you have one, before condemning either.
For the permanent install, pick the cable and connectors from cables or the accessories finder, and build the full camera link step by step:
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
More link-level debug walks, from enumeration to frame-rate drops, sit on the systems topic page. If the isolation path leaves an open question, the contact page reaches our applications team with your dmesg log.
Questions
Are the unknown pixelformat messages a problem I must fix first?
No. They are warnings from the V4L2 core while an application enumerates FourCC depth formats the stock kernel build does not name, and they print even on a link that streams for hours. Confirm formats with v4l2-ctl --list-formats-ext on each node (video0, video1 and video2 on a three-node camera) and spend your time on the completion-handler codes instead.
Can I extend the camera with a USB 2.0 extension cable I already have?
No. The extension caps the whole path at high-speed, where isochronous video tops out near 24.6 MB/s, and a three-stream VGA depth camera needs about 55.3 MB/s. The first symptom is a frame timeout, not a warning. It also adds a connector pair where SuperSpeed drops. Use one certified USB 3 cable of the length the run needs, routed away from motor drives.
How do I stop suspend from killing the link?
Two settings, both in the operating system. Exclude the camera from USB autosuspend, which most distributions expose as a per-device toggle in their power settings, and stop the machine suspending while it captures. A camera that runs unattended needs both: resume leaves UVC devices half-initialised, and the first transfer after it completes with an error code.
Does a self-powered hub slow the camera down?
Not by itself. A self-powered USB 3 hub keeps the SuperSpeed path and feeds the camera from its own adapter, so the host port stops being the power limit. Sharing only matters upstream: about 55.3 MB/s of streams leaves most of the roughly 400 MB/s a SuperSpeed uplink delivers. But a second camera on the same hub doubles that load, so move heavy neighbours to another port.
When is the camera itself the verdict?
When the drop survives the full path: rear SuperSpeed port, one short certified cable, self-powered hub, autosuspend off, and a second host. The strongest evidence is a second unit of the same model streaming for hours on the same port and cable. At that point stop debugging the link and start the return or warranty claim.