The kernel log is the single most useful diagnostic on an Antminer S17-series unit (S17, S17 Pro, S17+, T17, T17+, S17e, T17e). It records what the control board saw at boot and during runtime — how many chips each chain enumerated, whether the temperature sensors and EEPROMs answered on the I2C bus, whether the fans spun up, and whether any protection tripped. Read it correctly and you can usually name the failed board and the failed subsystem before you pick up a screwdriver. This guide maps the common S17 kernel-log messages to their real causes and the correct fix.
Accessing and reading the kernel log
Open the miner’s web dashboard, go to System → Kernel Log (some firmware labels it Miner Log or Log). The page dumps raw kernel and miner-daemon output as plain text — scroll to the bottom for the most recent boot, or copy the whole buffer into a text editor so you can search it. If the web UI is unreachable, the same stream is available over SSH.
The S17 platform’s control board runs an embedded Linux that enumerates and manages the hashboards, so it is the part writing the kernel log you are reading. Its three hashboards are addressed as Chain0, Chain1, and Chain2, and almost every hardware message names the chain — so the first move is to note which chain is complaining, because that tells you which board to pull. Each board carries the BM1397 (7 nm) hashing ASICs, a PIC16F1704 for chain control and communication, one I2C EEPROM (board ID plus frequency/voltage calibration), and several I2C temperature sensors, all talking to the control board over the 18-pin ribbon cable.
Common S17-series kernel-log errors and fixes
1. Fan error
Messages like fan lost, fan_num mismatch, or a fan reading well below its expected RPM mean the daemon isn’t getting a valid tachometer signal from one of the four fans. The firmware treats this as a safety fault and will refuse to ramp the boards.
- Power down, then reseat the fan connector at the control board header — the 6-pin plugs back out under vibration. Inspect the cable for chafing or crushed strands.
- Spin each fan by hand. A fan that grinds, wobbles, or won’t coast has a failed bearing — swap in a known-good fan of the same rating and connector.
- If a known-good fan on the same header still reads zero, the fault is the control board’s fan channel, not the fan.
Common mistake: a slightly-slow fan is often just clogged with dust — clean it before condemning it.
2. EEPROM error
Data of Chain[X] EEPROM is invalid or read eeprom error means the control board could not read valid calibration data from that board’s EEPROM over the I2C bus. This is a hashboard-side fault, not a control-board firmware problem — the EEPROM lives on the hashboard itself.
- Power down and reseat the 18-pin ribbon at both ends. Check for bent or recessed pins and pushed-back sockets; the EEPROM and temp sensors share the I2C lines on that cable, so one bad pin kills both.
- Swap in a known-good ribbon to rule out the cable.
- If the error follows the board to a good cable, the EEPROM IC or its I2C bus on that board has failed and needs board-level repair.
3. Missing chips / short ASIC count
A line such as Chain[X] only find NN asic (fewer than the board’s full chip count) tells you the ASIC chain broke somewhere. The number is a clue: if the log finds 30 of the expected chips, the chain is opening at roughly chip 31 — the fault is at or just after that position. Voltage is delivered per-domain (a group of chips shares one DC-DC converter), so a single dead domain drops a block of chips at once.
- Reseat and then swap the ribbon — a marginal cable is the cheapest cause of a short count.
- If the count is stable and repeatable at the same position, suspect a dead chip, a cold-solder joint, or a cracked board at that spot. That is a chip-level reflow or replacement job.
Common mistake: a short chip count is a chain/hashboard fault, not a PSU fault. Don’t swap the power supply for this — a bad PSU makes a whole board vanish (see below), not lose a handful of chips mid-chain.
4. Failed to read temperature sensor
Chain[X] read temp error or a sensor reporting an impossible value points to the same I2C bus the EEPROM uses. Because the temp sensors and EEPROM sit on the same two wires, a ribbon or bus fault often trips both errors together.
- Power down, reseat the ribbon, then swap it for a known-good one.
- If a good cable doesn’t clear it, a temperature-sensor IC or the board’s I2C bus has failed — board-level repair.
Never run a board with a dead temperature sensor: the firmware has no thermal feedback for it and can cook it.
5. Overtemperature protection
When chip or board temperature exceeds the safe ceiling, the firmware holds the affected board in reset and drops it — the log records the trip. This is the miner protecting itself, so treat the reading as real and fix the cooling:
- Clear dust from the heatsinks and fan blades; check that intake and exhaust are unobstructed and that hot exhaust isn’t recirculating back into the intake.
- Confirm all four fans reach full speed under load.
- Check ambient temperature at the intake — an S17 dumps a lot of heat, and a poorly ventilated room will keep tripping this no matter how clean the unit is.
Bitmain publishes a detailed walkthrough for over-temperature handling in their support knowledge base.
6. Low-temperature protection
The flip side: if the intake air is too cold at start-up, the firmware refuses to begin hashing to avoid condensation and thermal shock on the silicon, and the log notes the hold. This is normal cold-start behaviour in an unheated hashcenter or garage. Pre-warm the intake — recirculating a little exhaust or letting the room come up to temperature before energizing the boards clears it.
7. A whole hashboard missing
Chain[X] not detected — the board never enumerated at all — is different from a short chip count. Suspect power delivery first: check the board’s power lead and the torque on the bolted bus-bar (the S17 uses a bolted bus-bar, not per-board plug connectors), and confirm the PSU holds voltage. S17-series units ship with the APW9/APW9+, which run on 110/120 V but at reduced output, so an under-fed supply can let a board drop out under load while the others keep hashing. If power is solid and the board still won’t appear on a known-good ribbon, the board is the fault.
Before you RMA
Work the log methodically before condemning a board. Reseat and swap the ribbon on any I2C-related error (EEPROM, temp sensor, short chip count) — the cable is the most common and cheapest cause. Note which chain the error names and swap boards between positions to prove whether the fault follows the board or stays with the slot. A factory reset or a clean reflash of official, signed Bitmain firmware from the vendor portal is worth trying when the control board misbehaves, but it will not fix a hashboard hardware fault. Respect the power section: the low-voltage DC bus is harmless to touch, but the mains-side PFC capacitors in the PSU hold roughly 400 V for minutes after unplugging — let it discharge.
Related: Match a specific message to a component with the ASIC Fault Finder, source ribbons, fans, and hashboard components from ASIC Repair Parts, and if the fault is board-level, start a repair and send it in.
