You flashed JetPack 5.1.2, the MIPI camera that streamed for months on 5.1.1 now dies at probe, and dmesg ends with probe of 9-001a failed with error -34. This guide is for engineers bringing up camera modules on a Jetson Orin-class carrier. You will read the trace stage by stage, rule out the two suspects that waste the most time — module signing and I2C wiring — fix one gain property in the device tree, and decide when a camera with a shipped driver beats another week of kernel logs.
What does camera driver probe error -34 mean?
Camera driver probe error -34 is -ERANGE, the kernel's 'value out of range' code: your driver read the mode's control ranges back from the device tree, found the gain range invalid, and aborted the probe before registering the camera subdev.
Linux drivers report failures as negative errno values, and 34 is ERANGE — a result that cannot be represented, which for a control means a value outside its declared [min, max]. During probe, the tegracam camera-common framework parses your mode table, powers the sensor, then updates every mode-specific control range. The gain update is where this failure fires, and the trace prints the whole chain:
test_imx485 9-001a: Probing for sensor eimx485
test_imx485 9-001a: tegracam sensor driver:imx485_v1.0.9
test_imx485 9-001a: cam_power_on: power on
test_imx485 9-001a: ctrl Gain range update failed
test_imx485 9-001a: Error -34 updating mode specific control ranges
test_imx485 9-001a: Error -34 updating control ranges
test_imx485 9-001a: tegra camera subdev registration failed
test_imx485: probe of 9-001a failed with error -34
Read it in order: the bus answers, the driver identifies the sensor, prints its mode table (width=3840 height=2160 frate=33, width=1920 height=1080 frate=60), powers the rails, and only then fails at range registration. A failure this late cannot be wiring or power. Different error numbers mark earlier or later stages: -121 (EREMOTEIO) dies before any mode table prints, which the MIPI camera probe failed error -121 guide walks line by line. A probe that succeeds but never delivers frames is a capture-stage problem entirely.
Why did the same driver work on JetPack 5.1.1 but fail on 5.1.2?
Nothing on your board changed: JetPack 5.1.2 ships L4T 35.4.1, and that release validates every mode's control ranges at probe time, so a gain minimum that 5.1.1 accepted silently now fails the check with error -34.
Your .ko is byte-identical, your DTB is byte-identical and the sensor still answers, so the variable is the camera-common framework that ships with the release. The trace carries its own evidence: the banner still reads tegracam sensor driver:imx485_v1.0.9, meaning the module loaded and ran. An out-of-tree module that is incompatible with the new kernel refuses to load at all with a version-magic error — a different message from error -34. The same abort has been reported on other IMX-series modules, IMX477-class included, after the same 5.1.2 update. That pattern is what a framework-side gate looks like rather than a sensor defect.
Budget the fix accordingly: this is a one-property edit in your own tree, not a driver rewrite. If the driver-and-DTB pairing has drifted from what the release expects, start with the camera driver device tree mismatch guide.
Is the module verification warning the cause?
No: the 'module verification failed' line only taints the kernel because your driver is out-of-tree, and the trace keeps doing successful work for roughly 59 ms after it, so signing is not what stops this probe with error -34.
Taint is bookkeeping, not an abort. Work the arithmetic from the timestamps: the taint line prints at 10.771641 and the gain failure at 10.830461, and 10.830461 − 10.771641 = 0.058820 s. In that 59 ms the driver probed the sensor, read its identity, powered it on and parsed two video modes — nothing between those lines failed.
Rebuild the module with signing keys if your deployment requires signed modules, but do not expect it to change error -34: the failure fires after the module is loaded, running and talking to the sensor. If you see no 'Probing for sensor' line at all, the module or its I2C link is the suspect, and the camera I2C communication failure guide is where that hunt starts.
How to confirm the gain range is what failed
The framework names the rejected control one line above the first 'Error -34', so the log does the triage for you: on this failure that line reads 'ctrl Gain range update failed' — gain, not exposure, not frame rate.
Work down the causes in this order:
| Line above the first Error -34 | Most likely cause | Test |
|---|---|---|
| Gain range update failed | min_gain_val sits below the linear-scale floor of ×1.0 | set it above 1, rebuild, re-probe |
| Gain range update failed, minimum already above 1 | maximum below the minimum, or a step of 0 | check min < max and the step is non-zero |
| A different control named | that control's mode range is inconsistent | read that control's floor the same way |
The row-one test doubles as the fix and takes minutes: one property, one DTB rebuild, one reboot. Gain is the control this gate usually catches because linear-scale modules declare gain as a multiplier, and unity is ×1.0 — no sensor produces ×0 gain, so a floor of 0 is out of domain. Exposure and frame-duration ranges fail the same way when a mode block contradicts the top-level node. The runtime version of the same discipline — read a control's range before you write it — is the subject of query the option range before setting exposure or gain.
What exactly to change in the device tree
Set min_gain_val in the sensor's device tree node above 1 in linear scale — unity gain is ×1.0, so a minimum of 0 advertises a gain no sensor can produce — then rebuild the DTB and re-probe; the driver binary stays untouched.
- Find the sensor node your driver bound: the I2C address in the log (9-001a in the trace above) is the bus address of that node in the device tree source.
- Locate min_gain_val — check the mode block first, then the top-level node, because a mode value overrides the top-level one.
- Set it above 1 in linear scale: for a multiplier-style driver that is unity ×1.0 or the first step above it.
- Leave max_gain_val and the step untouched unless your edit leaves the minimum at or above the maximum.
- Recompile the device tree source with the device tree compiler and install the resulting blob the way your carrier board's flashing flow does.
- Reboot and grep dmesg again: success looks like the bound line from a healthy sensor ('subdev … bound'), followed by a capture test through your normal path, nvarguscamerasrc or a raw V4L2 read.
Worked example. A module tree declares min_gain_val = 0, max_gain_val = 32, step 1, linear scale. The driver's floor is unity, ×1.0, but the framework is asked to advertise [0, 32]. The check min_gain_val ≥ 1.0 fails because 0 < 1.0, the control setup returns -34 and the probe stops. Raise the property to 2 and the advertised range becomes [2, 32] — 32 − 2 = 30 steps, every one producible — and the probe completes. The functional cost sits at the bottom of the range: the driver can never apply less than ×2 again, so a bright scene loses a little highlight headroom and should trade gain for exposure time where the mode allows it.
What else moves between JetPack releases?
Treat every JetPack jump as a camera-framework update, not just a kernel refresh: 5.1.2 tightened camera-common validation, so anything your release passed before deserves a fresh probe test, and the error number in dmesg tells you which stage moved.
Check four things after any JetPack or L4T bump:
- Range validation — the gate covered above; grep dmesg for 'range update failed' before anything else.
- Module load — a .ko built against the old kernel reports a version-magic error and never prints its banner; rebuild it separately from the DTB.
- Capture path mapping — once the probe succeeds, confirm the camera index your capture stack opens before blaming the sensor.
- Runtime control behaviour — frameworks also change how gain and exposure writes are applied, which is its own symptom class; the V4L2 exposure and gain settings ignored guide covers it.
Keep the error numbers straight and each one points at a different stage: -34 is a software range check on a sensor that answers; -121 or -110 is the bus or a timeout; a clean probe with no frames afterwards is the capture stage, which the sensor detected but frames time out guide picks apart.
When to stop patching the driver and change hardware
Commit to the device-tree fix when the module's vendor publishes a corrected tree for your release — it is minutes of work and keeps your MIPI lanes — and change hardware when no vendor tree exists and bring-up has already consumed weeks.
Board-level cameras over USB3 or GigE ship their driver with the module, so the Jetson side becomes a user-space application: no camera DTB to maintain, no out-of-tree .ko to rebuild, no framework gate to re-test at the next update. You keep your lens and illumination; you spend a USB3 port or a network drop and give up direct sensor-register access. For inspection that moves onto a production line rather than an embedded board, the same logic holds across the area scan cameras range — GigE and USB3 models come up the same way.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.8"
- Interface
- USB3
- Sensor format
- 1/1.8"
- Lens mount
- CS-mount
The LS-BCM-0003 reads 3.1 MP at 120 fps over USB3 from a 1/1.8-inch global-shutter IMX252. The MV-CB060-10UM-B carries 6 MP of mono IMX178 over USB3 on a bare board you mount in your own housing. For a host with no USB3 headroom, the LS-BCM-0020 delivers 6.3 MP over GigE at 18 fps behind a CS-mount lens. Before ordering, check the host-side fit with the board camera sensor compatibility guide, score the module against the board camera evaluation checklist and browse the rest of the board-level cameras range.
How to keep the next JetPack update from breaking cameras again
Keep the out-of-tree driver, the sensor device tree and a probe smoke test in one repository, and after every JetPack update rebuild the DTB, boot once, grep dmesg for range failures and read each control's limits before the image ships.
Prevention fits in four habits:
- Tag the driver, the DTB source and a boot-and-probe script together, so a release bump rebuilds all three as one unit.
- After every L4T update, boot once and grep dmesg for 'range update failed' and 'failed with error' before the image ships to a machine.
- Write the driver banner line with its version — the tegracam sensor driver:imx485_v1.0.9 style line in the trace — into your release notes; it is the first thing to compare when behaviour changes.
- Have the application read each control's range at startup instead of writing hard-coded gain and exposure values.
If this trace is yours, make the one-property edit and re-probe today — the fix is measured in minutes. If the decision goes to new hardware, the camera finder filters by interface, resolution and shutter, and more probe and capture troubleshooting lives on the systems topic page.
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.
Questions
Does the same range check also cover exposure and frame rate?
Yes. The framework validates every mode-specific control the same way at probe, and the line above the first 'Error -34' names whichever one failed. Gain is simply the one most module trees get wrong in linear scale. If your trace names exposure or frame rate instead, read that control's declared minimum the same way: it must sit inside what the sensor can actually produce.
Do I have to rebuild the kernel or the driver to change the gain range?
No. The range lives in the device tree, so the kernel image and the out-of-tree .ko stay as they are. Recompile only the DTB — or the camera overlay, if your carrier uses one — with the device tree compiler, install it the way your flashing flow puts blobs on the boot partition and reboot. The driver picks the corrected range up at the next probe.
How is probe error -34 different from probe error -121?
-34 is -ERANGE: the sensor answered on I2C, its identity and mode table were read successfully, and a software range check then failed. -121 is -EREMOTEIO, a transport failure — the module got no reply from the sensor at all, so the trace ends before any mode table prints. Different stages, different starting points: bus and power for -121, device tree for -34.
Does raising the minimum gain hurt image quality?
You lose the bottom of the range, not the top. After the fix the driver cannot apply less than its new minimum — ×2 in the worked example — so bright scenes give up a little highlight headroom. Compensate with a longer exposure where the mode allows, or pick a minimum just above unity rather than a large step, and the visible cost is close to nothing.
What does the equivalent fix look like when a driver reports gain in decibels?
In decibel scale, unity is 0 dB, so the property that trips the check is a minimum below 0 — the same out-of-domain idea as a linear minimum below ×1.0. Raise that minimum to 0 dB or the first valid step above it. Linear-scale modules are the ones this gate usually catches, because a multiplier floor of 0 is the natural typo.