https://tibbo.com/downloads/archive/ioninja/.internal/prerelease/ioninja-5.3.1-b-linux-arm64.deb
https://tibbo.com/downloads/archive/ioninja/.internal/prerelease/ioninja-5.3.1-b-linux-arm64.tar.xz

Tried it on the latest ArchLinux -- it's working now.

Let me know if you notice any issues.

Please try it and let me know:

https://tibbo.com/downloads/archive/tdevmon/tdevmon-3.3.11/tdevmon-3.3.11-linux-arm64.tar.xz

Re ioninja-hwc -- I wouldn't expect issues on Aarch64; it's a simple console app that does no platform-specific trickery.

(I've checked that the linux-headers and the kernel version match)

Just fyi, also I tried the "GUI" ioninja, and it gave me an error when "JITting", e.g., going to use the "serial tap" plug-in... but perhaps it is normal and expected, as we have just been talking about the "ioninja-hwc" (and "tdevmon")

Regards!

Let me know if these work for you!

It took me a while to address the write protection removal issue on aarch64, but I finally got tdevmon working on aarch64; there's also an experimental build of IO Ninja for aarch64. Would you be willing to test those? Which is the most important module for you, ioninja-hwc or tdevmon?

Yes, ioninja-5.3.0 is out; it's quite a big release. Please try it and let me know what you think of the new form UI!

As for Aarch64 builds -- yeah, we still don't have those, sorry. I remember @bob was working on porting tdevmon to Aarch64, and I extracted and prepared a repo for this project, but I didn't receive any pull requests since, so I guess it didn't quite work out

Making an Aarch64 build for ioninja-hwc should be relatively easy. However, it should be possible to run an ARM build of ioninja-hwc on Aarch64 boxes directly, no?

In any case, I guess, it's time for us to dedicate some actual efforts to the Aarch64 Linux builds of IO Ninja & tdevmon

Merry Christmas and Happy New Year to you, as well!

I installed ArchLinux for ARM, and you were right. It does segfault over there -- while it doesn't on Raspbian with nearly the same kernel version.

After an investigation it turned out that the difference is that the kernel for ArchLinux is built with CONFIG_ARM_LPAE (support for Large Physical Address Extension) while Raspbian kernel is built without one. I remember testing write protection removal on ARM LPAE kernels, but that was with a relatively old kernel. In recent kernels, a slight modification in PMD (Page Middle Directory) flags is required.

Keeping the write protection removal code compatible with new Linux kernels is the whack-a-mole game. It works, then a new kernel comes out, and it stops compiling or working; you bring it up to speed, and it works again until the next breaking change in the kernel...

Anyway, please try tdevmon-3.3.10 (https://tibbo.com/downloads/archive/tdevmon/tdevmon-3.3.10/tdevmon-3.3.10-linux-arm32.tar.xz) and let me know if it works for you.

I've tried the 3.3.8 and first I was not able to compile it

I quickly look at lkmUtils.c, and I see there a difference between 3.3.8 and 3.3.9_a.

I just copy this section from 3.3.9_a into 3.3.8, and then I could make it. But the when I run the tdevmon.bin (obviously, after installing the built module), I had got the same "Segmentation Fault" error. Hope it helps

Regards... and have a Happy Xmas!
Josep

Just so that we are on the same page -- the segmentation fault happens in the kernel module, not in the app. So, after unpacking the 3.3.9-a patch, you need to rebuild the tdevmon.ko module from the updated sources -- not simply run the new bin/tdevmon.

If a segmentation fault occurred earlier, you might be unable to unload tdevmon.ko, so it's better to reboot to ensure the old module is gone.

If the segmentation fault still occurs, could you please try v3.3.8 from the archive:

https://tibbo.com/downloads/archive/tdevmon/

The regression under suspicion was introduced in v3.3.9 (and -- presumably -- fixed in v3.3.9-a). If v3.3.8 still crashes, it might be for a completely unrelated reason. Once again, the important thing is to ensure you rebuild and reload tdevmon.ko

If the segmentation fault still occurs, I will investigate further. Originally, I tried it on Raspberry Pi 3 with the latest Raspbian with a modern Linux-5.15 kernel, and it worked; I might need to get the exact version of the kernel (maybe, even the exact distro).

@vladimir said in tdevmon - segmentation fault:

Hello Jose,

Finally, found some time to check the issue -- and guess what? Turns out, it was already solved before -- but the download link was reverted back to the previous version for some reason. In any case, please take the patched version v3.3.9-a and try that one; it should work.

Well, I am sorry but I have to say that this patched version behaves to me exactly as the previous one, so I get the same "segmentation fault" error. If I could provide any other information that could be useful to you, please let me know.

Regarding the njlog forma

Now, to your other questions.

does tdevmon save the data in njlog format?

No, it doesn't, but that's because it's not possible to do in the general case. Thing is, the format of IOCTL parameters is device-specific, so the job of decoding IOCTLs and writing proper .njlog records lies on a particular plugin (such as Serial Monitor, Pipe Monitor, Mailslot Monitor, the upcoming USB Monitor, etc). Yes, it's theoretically possible to emit a severely trimmed version of .njlog that would contain read-s and write-s only (which are universal), but that's a serious limitation, so I'm not really sure such a feature would be useful.

I get the point. A pity, but you are absolutely right.

perhaps you could consider to release the Arm version also for 64 bit architecture (just the tarball)

Yes, that definitely can and should be done. As a matter of fact, just a day ago @bob suggested porting tdevmon to AArch64 so we might get something in this department very soon.

Thank you!!
Regards

Finally, found some time to check the issue -- and guess what? Turns out, it was already solved before -- but the download link was reverted back to the previous version for some reason. In any case, please take the patched version v3.3.9-a and try that one; it should work.

Now, to your other questions.

does tdevmon save the data in njlog format?

No, it doesn't, but that's because it's not possible to do in the general case. Thing is, the format of IOCTL parameters is device-specific, so the job of decoding IOCTLs and writing proper .njlog records lies on a particular plugin (such as Serial Monitor, Pipe Monitor, Mailslot Monitor, the upcoming USB Monitor, etc). Yes, it's theoretically possible to emit a severely trimmed version of .njlog that would contain read-s and write-s only (which are universal), but that's a serious limitation, so I'm not really sure such a feature would be useful.

perhaps you could consider to release the Arm version also for 64 bit architecture (just the tarball)

Yes, that definitely can and should be done. As a matter of fact, just a day ago @bob suggested porting tdevmon to AArch64 so we might get something in this department very soon.