Issue with FW 3.25 on RMPP

[oscarbranson]

New to ReMarkable, and excited to try out this repo.

In 3.25.1.1 when I run goMarkableStream I get:

./goMarkableStream
Version: v1.2.0
Local IP address: 192.168.1.217
2026/02/24 20:04:27 JWT: Loaded secret key from /home/root/.config/goMarkableStream/secrets/jwt_secret.key

But then hit ERR_CONNECTION_REFUSED when attempting to access from a browser (at 192.168.1.217:2001). netstat shows that nothing is listening on 2001.

Is this a version incompatibility? Or have I missed something obvious?

[owulveryck]

I don't know.

Maybe you can try a différent port with RK_SERVER_BIND_ADDR=:8888 for example

[eqvinox]

Same here. It looks like the code just never reaches the point where it starts listening, i.e. hangs somewhere after loading JWT but before listen.

It also uses 100% CPU on one core. Infinite loop or something? Looks like you started using Claude Code, maybe it generated trash?

[eqvinox]

Here's some strace -ff -e \!futex,rt_sigreturn,lseek,read,nanosleep,epoll_pwait,sched_yield,getpid,tgkill -e signal=SIGINT ./gomarkablestream-RMPRO output:

[pid 16974] newfstatat(AT_FDCWD, "/proc/391/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 16974] readlinkat(AT_FDCWD, "/proc/391/exe", "/usr/bin/xochitl", 128) = 16
[pid 16974] openat(AT_FDCWD, "/proc/391/mem", O_RDONLY|O_CLOEXEC) = 3
[pid 16974] fcntl(3, F_GETFL)           = 0x20000 (flags O_RDONLY|O_LARGEFILE)
[pid 16974] fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
[pid 16974] epoll_ctl(4, EPOLL_CTL_ADD, 3, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data=0x7fffc762b5000003}) = -1 EPERM (Operation not permitted)
[pid 16974] fcntl(3, F_GETFL)           = 0x20800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
[pid 16974] fcntl(3, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
[pid 16974] openat(AT_FDCWD, "/proc/391/maps", O_RDONLY|O_CLOEXEC) = 6
[pid 16974] fcntl(6, F_GETFL)           = 0x20000 (flags O_RDONLY|O_LARGEFILE)
[pid 16974] fcntl(6, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
[pid 16974] epoll_ctl(4, EPOLL_CTL_ADD, 6, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data=0x7fffc762b5000004}) = -1 EPERM (Operation not permitted)
[pid 16974] fcntl(6, F_GETFL)           = 0x20800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
[pid 16974] fcntl(6, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
[pid 16974] close(6)                    = 0
[pid 16974] openat(AT_FDCWD, "/proc/391/mem", O_RDONLY|O_CLOEXEC) = 6
[pid 16974] fcntl(6, F_GETFL)           = 0x20000 (flags O_RDONLY|O_LARGEFILE)
[pid 16974] fcntl(6, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
[pid 16974] epoll_ctl(4, EPOLL_CTL_ADD, 6, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data=0x7fffc762b5000005}) = -1 EPERM (Operation not permitted)
[pid 16974] fcntl(6, F_GETFL)           = 0x20800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
[pid 16974] fcntl(6, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
[pid 16973] sched_getaffinity(0, 8192, [0 1 2 3]) = 8
[pid 16973] sched_getaffinity(0, 8192, [0 1 2 3]) = 8

So it opens the memory of xochitl then unsuccessfully tries to poll on the memory… why does it try to poll the memory? That makes no sense, memory isn't pollable… (this might be normal and just Go being weird)

[eqvinox]

Looks like it can't find the framebuffer maybe?

Some more output:

$ ssh root@10.11.99.1 cat /proc/391/maps | grep -A 2 dri/ | awk '{ split($1, arr, /-/); printf "%-90s  // size:%d\n", $0, strtonum("0x" arr[2]) - strtonum("0x" arr[1]); }'                                                                                                    
ffff7cdfd000-ffff7cfaa000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7cfaa000-ffff7d157000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7d157000-ffff7d304000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7d304000-ffff7d4b1000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7d4b1000-ffff7d65e000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7d65e000-ffff7d80b000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7d80b000-ffff7d9b8000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7d9b8000-ffff7db65000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7db65000-ffff7dd12000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7dd12000-ffff7debf000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7debf000-ffff7e06c000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7e06c000-ffff7e219000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7e219000-ffff7e3c6000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7e3c6000-ffff7e573000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7e573000-ffff7e720000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff7e720000-ffff7f7f0000 rw-p 00000000 00:00 0                                             // size:17629184
ffff7f7f0000-ffff7f800000 ---p 00000000 00:00 0                                             // size:65536
--                                                                                          // size:0
ffff84022000-ffff841cf000 rw-s 00000000 00:06 287                        /dev/dri/card0     // size:1757184
ffff841cf000-ffff845f0000 rw-p 00000000 00:00 0                                             // size:4329472
ffff845f0000-ffff84600000 ---p 00000000 00:00 0                                             // size:65536

[owulveryck]

Oh; I am sorry. I (Claude) Made heavy changes but all of them are working on my RM2. Which version are you using ? Did you try with a previous one to see where it failed ? I am on holiday, i will have a look if possible by the end of the week. Le mer. 25 févr. 2026 à 19:22, David Lamparter ***@***.***> a écrit :

…

*eqvinox* left a comment (owulveryck/goMarkableStream#158) <#158 (comment)> Looks like it can't find the framebuffer maybe? Some more output: $ ssh ***@***.*** cat /proc/391/maps | grep -A 2 dri/ | awk '{ split($1, arr, /-/); printf "%-90s // size:%d\n", $0, strtonum("0x" arr[2]) - strtonum("0x" arr[1]); }' ffff7cdfd000-ffff7cfaa000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7cfaa000-ffff7d157000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7d157000-ffff7d304000 s-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7d304000-ffff7d4b1000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7d4b1000-ffff7d65e000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7d65e000-ffff7d80b000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7d80b000-ffff7d9b8000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7d9b8000-ffff7db65000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7db65000-ffff7dd12000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7dd12000-ffff7debf000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7debf000-ffff7e06c000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7e06c000-ffff7e219000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7e219000-ffff7e3c6000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7e3c6000-ffff7e573000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7e573000-ffff7e720000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff7e720000-ffff7f7f0000 rw-p 00000000 00:00 0 // size:17629184 ffff7f7f0000-ffff7f800000 ---p 00000000 00:00 0 // size:65536 -- // size:0 ffff84022000-ffff841cf000 rw-s 00000000 00:06 287 /dev/dri/card0 // size:1757184 ffff841cf000-ffff845f0000 rw-p 00000000 00:00 0 // size:4329472 ffff845f0000-ffff84600000 ---p 00000000 00:00 0 // size:65536 — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYL7KIB2ONTZW3GZRDURA34NXR4XAVCNFSM6AAAAACV6OBQXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNRRGE2DONRYHE> . You are receiving this because you commented.Message ID: ***@***.***>

[owulveryck]

@eqvinox I think you are right. I made the analysis with claude (It is a valuable help to have a quick understanding, but it is another story. I should blog about it).

Here is the result for information:

Root Cause: Infinite loop in internal/remarkable/pointer_arm64.go:106-122 (Paper Pro device initialization). The calculateFramePointer() function scans memory headers to locate the framebuffer, but has a
flawed loop condition that causes it to spin infinitely when memory headers contain unexpected values.

Problem Analysis

The Buggy Code

File: internal/remarkable/pointer_arm64.go:100-126

 length := 2
 for length < ScreenSizeBytes {  // ScreenSizeBytes = 14,061,312 bytes
     offset += int64(length - 2)  // BUG: If length stays at 2, offset never advances!

     if _, err := file.Seek(startAddress+offset+8, 0); err != nil {
         return 0, fmt.Errorf("failed to seek in memory file: %w", err)
     }
     header := make([]byte, 8)
     _, err := file.Read(header)
     if err != nil {
         return 0, fmt.Errorf("error reading memory header: %w", err)
     }

     length = int(int64(header[0]) | int64(header[1])<<8 | int64(header[2])<<16 | int64(header[3])<<24)
 }

Why It Loops Infinitely

1. Initial state: length = 2, offset = 0
2. Loop condition: Continue while length < 14,061,312
3. Offset increment: offset += (length - 2)

• If length = 2: adds 0 → offset never changes
• If length = 1: adds -1 → offset moves backward
• If length = 0: adds -2 → offset moves backward

4. Memory read: Reads same/nearby memory location repeatedly
5. Result: If memory headers are zeros or small values, loop never exits

[owulveryck]

This is indeed a tricky issue that looks independant of the recent modification. It is more likely a change in the firmware that triggers the problem.

It looks like the infinite loop is just a symptom.

A deeper investigation with Claude code and the help of the information in this issue (thank you so much for doing this) led to a fix proposal. The fix is in a branch that is mention in the issue, but I have no possibility to test it as I don't own Remarkable Pro.

If any of you can compile and test the branch, I will merge it if it works. This is the best I can do.

[oscarbranson]

Thanks for the quick action @owulveryck ! I'm completely new to reMarkable, so probably not the best person to attempt a compile from source and debug... but will try to try if nobody beats me to it!

[owulveryck]

🙏

For info, thanks to the go programming language, the program can be compiled on your laptop (whatever os) and copied to your device. No need to install anything on your device (beside the resulting binary)

[eqvinox]

You're way faster than most commercial projects, for what I'm assuming is still a hobby project, and you're on holiday! ❤️👍 I'll try later today when I'm in front of my computer. (No problem with the build here, don't know any Go but do know my way around embedded work :D) P.S.: please don't let us disrupt your vacation and properly enjoy it!

…

On 26 February 2026 09:06:06 CET, Olivier Wulveryck ***@***.***> wrote: owulveryck left a comment (owulveryck/goMarkableStream#158) This is indeed a tricky issue that looks independant of the recent modification. It is more likely a change in the firmware that triggers the problem. It looks like the infinite loop is just a symptom. A deeper investigation with Claude code and the help of the information in this issue (thank you so much for doing this) led to a fix proposal. The fix is in a branch that is mention in the issue, but I have no possibility to test it as I don't own Remarkable Pro. If any of you can compile and test the branch, I will merge it if it works. This is the best I can do.

-- Sent from my smartphone. Please excuse my brevity.

[owulveryck]

Thank you very much for the kind words.
It is much appreciated.

It is indeed a hobby project, and I took this opportunity to learn and understand things. No worries; I enjoyed this investigation time. I don't feel any obligation to answer. Thank you for thinking about this ❤️

But knowing that this project is useful to the community is quite a good reward (its goal is to share screen, so it is used to share whatever, and sharing is caring ;).

[eqvinox]

Sorry about the delay, I got sidetracked at work :/ … it's not quite working yet, posted investigation results on PR #159