2026

Logcat read failure troubleshooting and fix record

After flashing lineage-16.0 on a retired OnePlus One, it had been running smoothly as a backup retro gaming device. Recently, when using it for Android debugging, I suddenly found that logcat was not responding. In Android Studio the log window was completely blank. The adb device status was normal, but running adb logcat or adb shell logcat showed the error ‘logcat read failure’.

I spent a long time investigating. I tried various methods. Rooted into /system/bin and confirmed that logd was intact. Some people suggested SELinux issues, so I checked with ls -Z and saw the permissions were u:object_r:logd_exec:s0, which looked fine. I suspected Magisk had broken the system, so I did a factory reset, but the error persisted.

Then I remembered that the system image I used previously was downloaded from some random website, and it came with many preinstalled junk apps. Maybe the ROM author had broken important functionality. So I searched and found an official lineage old version image: https://lineageosroms.com/bacon/#installing-lineageos-from-recovery

After reflashing with the pure official image, logcat worked normally again. Problem solved.

PS2 DS2 H controller 760020 board BU6370AK main chip conductive film replacement and repair

A friend had two H controllers. One was severely damaged: all buttons except the left and right sticks, L3, and R3 were nonfunctional (because years ago it was soaked in cola…). The other had L1, L2, and D-pad up and left failing, while the rest worked normally. Opening them up:

IMG_0756 IMG_0755
The back cover showed it was an H controller, with the board marked 760020 in white at the top left. This is the second version of the H controller. The conductive film under the button pads was marked 03-0241. On Taobao I found similar films for about 2 RMB each. Observing the connection between the board and the conductive film, I confirmed that the film connector and socket are integrated, with the socket pins soldered directly to the PCB. Comparing with my A controller, its conductive film is pressed directly onto the PCB. Taobao did not sell the original socket type film, but luckily one seller offered a similar 19-pin pluggable socket.
Looking at the PCB traces and referencing information that PS2 DS2 controllers support pressure sensitivity, the conductive film carbon contacts change resistance depending on button pressure, which the BU6370AK main chip converts into digital signals for the console. Examining the film traces, I saw that except for Select, Start, and Analog buttons, all carbon contacts shared one common line, corresponding to pin 9 from the left. Using a multimeter with one probe on pin 9 and the other on each button pin, pressing a button showed resistance changes from 0 to several kΩ (tested on the partially working controller). On the faulty buttons, it was open circuit. Comparing traces, L1, L2, D-pad up, and left corresponded to the leftmost pins, while D-pad down (which worked) was the next pin after left. So I concluded those four buttons had broken traces on the film. The other controller was worse: all buttons failed, only the analog sticks worked. Despite the cola damage, the main chip seemed fine. So I ordered replacement films and sockets from Taobao.

Continue reading…

Systemd – Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd

While configuring a Debian 11 virtual machine with 128M memory, I ran into an error when reloading systemd service configuration. The error message was as described in the title. After investigation, I found that Debian by default allocates /run space proportional to system memory. With only 128M memory, the default /run size was 16M. When executing systemctl daemon-reload, the error appeared, along with a message like:

Currently, XX.XM are free, but a safety buffer of 16.0M is enforced.

The solution is simply to increase the /run size. Modify /etc/fstab and add the following line:

none /run tmpfs defaults,size=64M 0 0

This specifies 64M space for /run. According to online sources, this should be sufficient for most cases. Then execute:

mount -o remount /run

to remount /run. After completion, use df -hT to confirm the current size of /run. Once increased, running daemon-reload works normally again.

A record of fixing an Altium Designer Health Check issue

As shown in the screenshot, while learning PCB design in AD recently, I discovered that besides DRC checks, AD also has a Health Check feature (the version used when writing this was 25.8.1). Several warnings appeared: Self-Intersecting Regions、Micro-Segments (Board)、Micro-Segments (Copper). This record mainly focuses on a strange issue encountered while fixing the first and third problems.

First, by clicking the issues listed:

You can locate the PCB area where the problem was detected. In my board, it pointed to this location:

Continue reading…

Altium Designer 24 PCB DRC Solder Mask Sliver constraint floating point precision issue

While learning AD24 recently, I discovered an issue:

As shown in the screenshot, AD’s DRC check reported a violation:
“[Minimum Solder Mask Sliver Constraint Violation] IP2369_EVM.PcbDoc Advanced PCB Minimum Solder Mask Sliver Constraint: (0.0998mm (3.929mil) < 0.1mm (3.937mil)) Between Pad U1-21 (52.014mm, 25.561mm) on Top Layer And Pad U1-22 (52.014mm, 25.961mm) on Top Layer [Top Solder] Mask Sliver [0.1mm]”

After investigating and manually calculating pad size, solder mask expansion, and pad spacing:

Continue reading…

W801 (W80X_SDK_v1.00.10) https request mbedtls error 0x7780 issue and solution record

The issue started when I wanted to use the W801 to detect a GPIO level change and then send a bot notification message through Telegram. However, when calling my own Telegram API reverse proxy (caddy v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=), the serial log showed the SSL handshake error 0x7780 mentioned in the title.

The code was directly copied from the SDK example demo wm_https_demo.c. The error occurred during the handshake, specifically when calling HTTPWrapperSSLConnect, as shown:

wm_printf("step 1: ssl connect to...\r\n");
ret = HTTPWrapperSSLConnect(&ssl_p, fd, (const struct sockaddr *)&server, sizeof(server), HTTPS_DEMO_SERVER);
if (ret < 0)
{
    wm_printf("https connect error\r\n");
    close(fd);
    break;
}

At first, the serial output only showed step 1: ssl connect to…, then immediately the 0x7780 error, followed by https connect error and request failure. After studying the mbedtls library used internally, I found that more detailed debug logs were available. You need to enable the macro define MBEDTLS_DEBUG_C in SDK src/app/mbedtls/include/mbedtls/config.h (and make sure the makefile project rebuilds the lib target. If using my previous CLion IDE setup, select the lib configuration and rebuild). After enabling it, you can see error messages similar to those mentioned here: https://forums.mbed.com/t/error-0x7780-during-handshake/6883

Continue reading…

One cause of GitLab built‑in CI runner submodule initialization error

First, the background: a GitLab project that references other projects within the same GitLab instance using submodules. The .gitmodules file looks something like this:

[submodule "lib1"]
	path = lib1
	url = http://gitlab.xxx.xxx/group1/lib1.git
[submodule "lib2"]
	path = lib2
	url = http://gitlab.xxx.xxx/group2/lib2.git
[submodule "lib3"]
	path = lib3
	url = http://gitlab.xxx.xxx/group3/lib3.git

This structure works fine during local development. Of course, the local GitLab account has access permissions to the dependent submodule repositories. When setting up the CI build environment, using GitLab’s docker runner on Linux works without issues. However, on macOS using the shell runner, I encountered errors when initializing submodules:

Continue reading…

Correct reset method for Xiaomi Mijia Temperature and Humidity Sensor 2 (reset, factory restore, contacts not pressable)

I have three Xiaomi Temperature and Humidity Sensor 2 devices at home, connected to the Xiaomi Smart Plug 2 Bluetooth gateway. They are small and convenient, allowing me to check home temperature and humidity anytime on my phone. Recently, after replacing the battery in one of them, a strange problem appeared: the device could be seen in the Mi Home app, and it showed as connected to the Bluetooth gateway, but no temperature or humidity data could be retrieved. Entering the device details page gave no response, only prompting “Turn on Bluetooth.” If I enabled phone Bluetooth, it would connect very slowly to the device and eventually retrieve data, but the process was sluggish, unlike before when the gateway connection was instant. This also meant that when away from home, I could no longer see real‑time data from this sensor (the gateway page in the app still showed the sensor connected with full signal). Later I checked the firmware and found it could be upgraded to the latest “0130.” I upgraded (the process was also very slow, probably due to Bluetooth transfer), but the problem remained! Searching online, I found people suggesting a reset, which brings us to today’s topic. The reset design of this Xiaomi sensor is rather unusual. Most online reset methods say this:

Continue reading…

A strange reason for QRhiGraphicsPipeline create failure

Recently while learning the Qt RHI graphics rendering framework I encountered a strange problem: QRhiGraphicsPipeline inexplicably returned false on create! During the time this problem appeared, I was debugging the fragment shader, specifically studying HDR display shaders, and frequently toggling Windows HDR on and off. At one point I thought it was a system issue, so I tried switching to SDR, but the error persisted.

Later, after spending some time reverting modifications, I finally isolated the cause…

First, note that the program framework was basically copied from the Qt official documentation example: https://doc.qt.io/qt-6/qtgui-rhiwindow-example.html. The error occurs at the following code location:

Continue reading…

Cherry MX2.0S RGB keyboard LED failure repair log again

Following the first repair of my Cherry MX2.0S RGB keyboard LED failure last October (Repair log of Cherry MX2.0S RGB keyboard lighting failure after more than 3 years), I recently found another group of keys (numeric keypad 9, 6, 3, DEL) showing the same fault:

This time my hand didn’t shake 😂, and I removed the keycaps and shot a video, the fault phenomenon is crystal clear!

Since I already had experience repairing this fault last time, this time I prepared to optimize the repair process and record the simplified steps.

Continue reading…