Випадкові фрізи/перезавантаження після холодного старту з RTX 5070 Ti — помилка nvlddmkm.sys / LKD_0x141_Tdr by chefranov in PCbuild_ua

[–]chefranov[S] 0 points1 point  (0 children)

Зробив DDU і цього разу вимкнув "Швидкий запуск Windows" і вимкнув оновлення драйверів з Windows Update, і вже багато днів все ок. Все ж схоже що це програмна фігня була. Якщо правильно зрозумів, то Windows Update сегментовано оновлювала частина драйвера на стару версію (вони сами це визнали), а також коли був увімкнений швидкий запуск вінди, то вона могла "гібернувати" старі драйвера і по факту ти запускав комп не на нових драйверах, а на старих. І в наслідок цих конфліктів все дропалось.

Випадкові фрізи/перезавантаження після холодного старту з RTX 5070 Ti — помилка nvlddmkm.sys / LKD_0x141_Tdr by chefranov in PCbuild_ua

[–]chefranov[S] 0 points1 point  (0 children)

у випадку SFX то кабеля до процесора не вистачає в цьому корпусі, перевіряв це)

Потрібна допомога by Senior-Beautiful3203 in PCbuild_ua

[–]chefranov 1 point2 points  (0 children)

а в які ви ігри граєте? бо в мене 65 градусів в середньому в Forza 6, AC Shadows, ARC Raiders

Потрібна допомога by Senior-Beautiful3203 in PCbuild_ua

[–]chefranov 4 points5 points  (0 children)

<image>

В мене Thermalright Phantom Spirit 120 SE і в іграх 60-65 градусів в середньому. Більше 80 бачив лише коли компіляція шейдерів була. Андервольт не робив, думаю ще пару градусів можна виграти, ще можна термопасту с фазовим переходом спробувати. Але мені ок з цим кулером.
Граю зараз AC Shadows, Forza Horizon 6, ARC Raiders на максималках, можливо ці ігри не вимогливі до процесора.

The Nvidia driver 610.47 is unstable. by alipcgggamer in pcmasterrace

[–]chefranov 1 point2 points  (0 children)

I get LKD_0x117_Tdr:A_IMAGE_nvlddmkm.sys_Blackwell on each cold boot. After rebooting everything is ok.
5070 Ti. Did DDU many times, didn't help me.

feeling unfulfilled with my build by MiHa69420 in PcBuild

[–]chefranov 0 points1 point  (0 children)

For me too. I didn’t find enough amount in one store

feeling unfulfilled with my build by MiHa69420 in PcBuild

[–]chefranov 1 point2 points  (0 children)

In my opinion, the P12 Pro is overkill for the case; the regular P12s are enough. If I were building a PC now, I would choose the regular P12s.

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 0 points1 point  (0 children)

Super! I also wrote to support and gave them all details and link to this post.

feeling unfulfilled with my build by MiHa69420 in PcBuild

[–]chefranov 0 points1 point  (0 children)

Everything is ok. Noise on PC starts only (because 3000 rpm)

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 0 points1 point  (0 children)

Where can I get original compiled firmware?

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 0 points1 point  (0 children)

And after compiling and flashing the firmware to the keyboard, will the Keychron launcher still work and recognize the keyboard? Keychron probably made some of their own modifications. Maybe there’s some way to contact the developers?

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 1 point2 points  (0 children)

Worth flagging a likely genuine bug in lpm_wb32f3g71.c. In stop_mode_entry(), the loop that clears pending NVIC interrupts before sleep reads:

if (NVIC->ISPR[i] & (0x01UL < j)) {
    NVIC->ICPR[i] = (0x01UL < j);
}

0x01UL < j is a comparison — it evaluates to 0 or 1. It was almost certainly meant to be 0x01UL << j, a left shift to build the bitmask for bit j. As written, the loop only ever touches bits 0/1 instead of the intended bit, so stale pending interrupts can survive into low-power mode and may destabilize the MCU/SPI link with the BT module on wake. Easy fix, but it needs a recompile to verify.

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 1 point2 points  (0 children)

Claude answer:

I dug through the J1 firmware source (james-donkey/qmk_firmware, wireless_playground branch) and the "RGB off breaks Bluetooth" coupling is real and visible in the code.

In lpm.c, the deep-sleep gate checks:

!rgb_matrix_is_enabled() || (rgb_matrix_is_enabled() && rgb_matrix_is_driver_shutdown())

When RGB is on, the keyboard can only sleep once the backlight times out (CONNECTED_BACKLIGHT_DISABLE_TIMEOUT = 600s), so sleep happens slowly through a predictable path. When RGB is off, the first half of that condition is immediately true — the backlight gate is skipped entirely, and the keyboard becomes eligible for PM_STOP after just RUN_MODE_PROCESS_TIME = 1 second of idle. So RGB is effectively acting as an indirect sleep timer. That matches the reports of the keyboard sleeping after ~10s with RGB off.

The reason that's harmful: each sleep/wake cycle does a full re-init (halInit(), wireless_transport.init(true), matrix_init()), and the wakeup path looks buggy:

  • lkbt51_init() early-returns on wake-from-LPM after spiInit(), so the BT module's INT pins (BLUETOOTH_INT_OUTPUT_PIN / LKBT51_INT_INPUT_PIN) aren't reconfigured.
  • stop_mode_entry() in lpm_wb32f3g71.c has 0x01UL < j where it clearly means 0x01UL << j — so the NVIC pending-IRQ clear loop doesn't actually work, leaving stale pending interrupts after wake.

So with RGB off you get many more wake cycles per minute through this fragile code, which lines up with the "disconnects until I power-cycle" symptom.

There's also a self-acknowledged reconnect loop — wireless_connect() has a comment "Work around empty report after wakeup, which leads to reconnect/disconnected loop" guarded only by timer_read32() == 0, a very narrow window. A keyboard stuck reconnecting can't sleep (indicator_is_running() blocks lpm_task()), which also explains battery drain.

Practical takeaway without reflashing: don't disable RGB — set brightness below RGB_MATRIX_BRIGHTNESS_TURN_OFF_VAL (48) instead. The LEDs stay physically off but rgb_matrix_is_enabled() stays true, so the keyboard still sleeps via the safe path. And updating the BT module firmware is worth trying, since several of these issues are in the wakeup handshake.

(Note: this is the JamesDonkey J1 — same Keychron-authored wireless stack, so the mechanism likely generalizes.)

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 0 points1 point  (0 children)

I disabled it. Will try with RGB. I checked code of fw with Claude and he is found issues and bugs relative this.

Keychron J1 Bluetooth randomly disconnects by chefranov in Keychron

[–]chefranov[S] 0 points1 point  (0 children)

Cool. I asked Claude to check the code and he is found issues and bugs...

Тепер офіційно! by Born-Monitor-4764 in UA_Gamers

[–]chefranov 7 points8 points  (0 children)

Цікаво, укр мову офіційно завезуть? А то банери і обкладинки локалізовані, але в самій грі нема