@mitu Ah thanks, that is good to know. But seems it doesn't have super pages enabled on that build, so I might just give it a shot and config it myself and see if it works.

If nothing else, it'll allow the system to switch to 4kb pages on the fly without having to change kernel to use aethersx2 or other abandoned applications in that situation

Edit: so I edited the above git pull to build with huge/super pages config on

pi@raspberrypi:~ $ uname -a Linux raspberrypi 6.13.0-v8+ #1 SMP PREEMPT Fri Jan 24 15:37:24 GMT 2025 aarch64 GNU/Linux pi@raspberrypi:~ $ cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never

I am noticing a slight increase in a few spots, for example I can push some of the flycast games up to a higher internal resolution. Not noticing too much change on the gamecube side of things, unless there's a game or two that runs at say 55fps or 27fps and it can be nudged into full speed.

So tried star fox adventures and it seems to goes from around 25fps in the area Fox first explores to a more manageable 47fps. With VI Skip on it becomes playable imo, if not at the original 60fps the game was at

One of the perils when updating to the bleeding cutting edge firmware.

Unless it is really needed I advise to stick to a kernel and firmware that works well on your setup and make it permanent and use a more cautious update than full-upgrade.

@beldar I don't notice tearing with SNES, NES, Genesis, Neo Geo, or Playstation. But I do notice it on Mortal Kombat 2 arcade which does run at a funky refresh rate. I also noticed it very badly with lr-flycast. Soul Calibur, MKGold, and NFL Blitz all had really bad tearing.

@renepela confirming lr-vice problems too, build fail on linux mint 19.3 x64 (RetroPie 4.6)

And it seems to be rolling out now - 1.20190401-1 is in the repository, so there's no need for rpi-update.

EDIT: eh, spoke to soon, 1.20190401-1 is still at 4.14.

@mitu Yeah, it seems to. I'll try to switch over to Pegasus, that may offer touch functionality.

Doh, OK, re-running the script after rebooting fixed it. I must not have rebooted since updating the kernel version. Now I can run jstest /dev/input/js0and see the buttons work as well as shutdown view soft power switch and see LED indicate status.

I'm not sure if this post will be useful to others, but one never knows. In any case, the process of writing it out probably helped me figure out what went wrong.

Here is another fact, I started a new image from scratch and moved exactly the same amount of roms, the system is duplicated manually in a fresh install and it takes 2.84 seconds more to load ES on the new PI3B+ running Retropie 4.4 than the PI 3B running 3.9, its akward, but true. I have an intro video wich overlays the ES loading screen and now I have to make it that time longer because Retropie 4.4. with a PI3B+ takes more time loading.

@swampy yeah that may have resolved it. Glad it's working.

@herb_fargus That seemed to work, thanks!

Related - see my reply, here:
https://retropie.org.uk/forum/topic/8091/noninteractive-installation-upgrades/7

@castroe_10 Etcher is meant to verify the image as part of the writing process. However, it may be a few things. The image you downloaded may be corrupt. It happens from time to time or the card may well be the issue. I suggest redownloading the image and starting afresh. If that doesn't yield a positive result try a different SD card.

@Dopy25 said in How To Apply Raphnet Kernel Patch To Fix "Northwest" Drift:

I know the last comment on this was over a year ago, but I am having issues applying these patches. Has there been any update to this process?

I am having the exact same issue as @Dhrystone from above. Second patch fails at 1 out of 1 hunk, 3rd patch at 2 out of 4 hunks. I tried repeating the whole process, and even proceeding anyway, but the patch still does not apply, and without the second (and third?) the only difference is that now emulation station is constantly scrolling.

I know this is a serious Necro, but I'd rather not lose all the progress on the thread.

I'm seeing the same issue here as @Dhrystone and @Dopy25.

Is anyone with a bit more kernel compilation experience able to offer some advice here?