The Cable That Wasn't: An AI Use Case for IT Ops

We run a multi-tenant GPU cloud on OpenShift, GPUs passed straight through to tenant VMs via OpenShift Virtualization for bare-metal performance on shared hardware. One tenant's VM had been crashing for weeks with unrecoverable GPU memory errors, already traced to one failing card. Time for an RMA. Routine hardware maintenance, on paper: power down, swap the card, close it back up.

The teardown

On paper. Reaching the failed card meant unplugging a cable under the fans, which freed a second cable running over the fans to the motherboard, which was itself pinned under an unrelated riser further forward. Free that riser, free the cable, free the fans, finally reach the GPU. Then reverse the whole sequence to seat the new card. A ten-minute swap turned into disassembling half the server to touch one connector.

The swap goes fine, until it doesn't

Reassembly went fine. Powering the node back on didn't. iDRAC refused, with a message I'd never seen before:

iDRAC / Lifecycle Log:

Unable to power on the host because a SL cable is connected to an unpowered device.

My instinct was that I'd knocked something loose during reassembly. But the last thing I wanted was to pull the server back out and start wiggling connectors on a guess. iDRAC was still reachable over the network, so instead of reopening the chassis, I stayed at my desk.

Round one: Reasoning from the error alone

Before opening anything up, I described the error to Claude Code. Working from the message alone, it got the category right immediately: not a GPU problem, a cable-presence interlock, Dell's safety check that refuses to power on rather than risk a device it thinks is only half connected. 

It pulled up a matching Dell community thread to back up the read, and explained that SL means slimline: the data cables running from motherboard to GPU riser. Solid, for something built off a one-line error and general Dell docs. But it wasn't a diagnosis, just the most likely story out of several candidate cables on a server with four GPUs, two risers and a PERC card sharing the same interlock.

Round two: Bring the logs

Rather than reopen the chassis on a guess, I generated a TSR (Technical Support Report) from the iDRAC console, Dell's on-demand diagnostic bundle, and handed the zip to Claude Code:

Prompt, sent with the TSR attached

I was replacing the GPU from the situation in the prior failure report. After replacing the GPU, the iDRAC is showing this error: Unable to power on the host because a SL cable is connected to an unpowered device. I believe it must be an issue with how I cabled things back. But can you give me better direction?

I just copied over the TSR zip. Unzip it and review the logs to see if you can pinpoint it.

Inside: plaintext debug logs, an XML export and raw binary dumps, none of it written for casual reading. The agent moved through it like a colleague would: unzip, map the directory, start with what's readable, then get specific. The System Event Log had the failure recorded, but only as a generic hex code, no connector name. So it moved into iDRAC's internal debug log, where the firmware check that made the decision had left a trace:

iDRAC internal debug log

_cable_check.1000: grounded slimline 13 not found in any one-wire payload, power up is aborted!

Every slimline cable grounds a presence-detect pin at the motherboard end, and every device on the far end reports back over a shared one-wire ID bus. SL 13 was  grounded but  unclaimed on that bus. iDRAC read it as a live cable running to a dead or absent device, and stopped.

That's specific and checkable: SL 13, not "a cable, somewhere." From there, a binary configuration dump of the active riser layout mapped which physical slot each of the six slimline cables fed:

One more check, to rule out a false read: a boot-time enumeration log showed which risers and cables the firmware actually found. Riser 1 itself was missing too, not just its cable. Two pieces of hardware going dark in the same boot meant one disturbance, not two coincidences.

The twist

The GPU I'd just replaced was innocent, its cable had enumerated cleanly. The real fault was a different riser entirely, the rear one carrying a network card, evidently bumped while I worked the GPU cage next to it.

"Pinpointed it. And it's not the GPU you replaced. The problem is rear Riser 1: either the riser itself isn't seated, or its slimline data cable got knocked loose at the riser end."

      Claude  Code, after reading the TSR

The error had been technically true: a cable was connected to an unpowered device. It just named the symptom, not the location. Left to my own instincts, I'd have spent the reopening pass right where I'd just been, re-seating the GPU and its power cable, before ever checking a NIC riser across the chassis.

Fix, and proof it held

1. Pulled both AC cords and held the power button to fully drain flea power, since the interlock state can latch until AC is actually removed.
2. Reseated Riser 1 and its slimline cable at both ends.
3. Left the GPU cage alone. All four GPU data cables, including the new card's, had already enumerated correctly.

Power came back clean. The next day, a GPU burn-in VM booted with all four cards visible, and the vendor diagnostic suite passed clean on every card, confirming the fix held under real load, not just at boot.

What actually changed

The agent didn't know the answer going in. It built one, and stayed explicit about the difference between the two rounds: a plausible read from an error string, versus a claim backed by a specific log line, checked against a second source, before it became the fix. That second step is easy to skip under time pressure, and the generic SEL code alone would have supported almost any cable theory.

Here's the number that actually matters: eighteen minutes from handing over the TSR to a connector-specific root cause, most of it the agent working through the bundle while I did something else. The realistic alternative wasn't eighteen minutes. It was reopening a chassis I'd just spent an hour reassembling, on a guess, probably in the wrong spot, or filing a support ticket and waiting on a person to read the same logs. That gap, eighteen minutes against however many hours, is the real story here, more than the specific cable.

The habit worth taking from this

Don't just describe the problem to the model and take the first answer. Hand it the primary evidence, the full TSR, the raw log, the actual file, and let it read all of it before anyone touches a tool. Used that way, it isn't a chatbot answering a quick question. It's the difference between a server down for a shift and one back up before anyone else notices it was ever off.