ioctl() errors that started to appear with kernel 6.1.21 #5524
Comments
|
How much RAM does the Pi 4 have? If it's 8GB, does putting |
It has 2 GBs. All my Pi4s are 2 GB. |
|
Do you just get a few at startup, or are they more continuous than that? I ended up installing Batocera (based on 6.1.25) a few weels ago for some testing (on an 8GB Pi 4) and SDLPoP runs OK, but the shell gets a few swiotlb full messages on startup: However, there was a significant change in the way DMA addresses are derived in our 6.1.28 kernel releases, and Batocera is currently still stuck on 6.1.25. |
I get them at SDLPop startup only, apparently there are no more after that. |
|
Running SDLPop from the RPiOs desktop launcher under 6.1.35 + KMS on both 2GB and 8GB Pis, and I see no errors. |
|
What does BTW, my mesa seems to be on 20.3.5. |
|
Make that |
That's it. |
|
Thanks. Can you tell me the top commit for one of the builds, and upload /sys/firmware/fdt somewhere I can grab it? Or email it to [email protected] if you prefer. |
I don't have a Also, I don't know what software build do you mean: kernel/fw? MESA? SDL2? Other? |
|
Ah well, sorry, ftd seems to be a file. Still, I don't understand what top commit do you need. |
|
The bug report is about the kernel, this is the kernel repo, I want the kernel top commit. Or is it one of our pre-built kernels? |
It is the latest kernel available in rpi-update. Sorry if my question sounded obtuse, but theres a graphics software stack on top of the kernel. Thats why I asked. |
|
A clean, fully-updated installation of 32-bit Raspberry Pi OS (but with the 64-bit kernel) shows no problems when I launch a freshly built SDLPoP. Running rpi-update on that gets the same kernel as you, and it is also showing no errors or issues of any kind with SDLPoP, even running at 4K. |
I have a full 64bit system, both kernel and libs. In fact, it's Raspberry Pi OS 64bit LITE. In fact, weren't you seeing them here? --> #5524 (comment) |
|
The few errors I was seeing were under Batocera, but that was limited to a 6.1.25 kernel. I want to reproduce them under RPiOS with a current kernel, so I'm now starting again with a 64-bit Lite image. |
You need to build latest stable libDRM, libSDL2 + SDL2_Mixer and latest stable MESA, all on top Raspberry Pi OS LITE, in order to replicate my setup. |
|
Running on 64-bit Lite on 6.1.25-v8+ in console mode -> no errors This is turning into a large effort sink for something that just works out of the box on RPiOS. Please give step-by-step instructions for installing the necessary elements to show the problem on a clean RPiOS Lite. |
|
@pelwell SDL2 building instructions follow. First of all, change to the ROOT user. We don't want to fiddle with permission nonsense on a microcomputer.
PART 1: LIBDRMUninstall old libdrm: Install libdrm deps:
Download, decompress and configure/build latest stable libdrm: PART 2: MESAInstall MESA's deps:
Download, config, build and install MESA: PART 3: SDL2Clean BCRM closed-source cruft to avoid problems: Install SDL2 deps: Download, configure and build: PART 4: SDL_ImageSince SDLPop needs this one, we will build and install it too. Download, config and install: PART 5: SDLPopAnd that's about it- |
|
That's really helpful, but I can't get it to work. There were various differences with my system, so I ended up with this installation script: After that, prince hangs with the following output: You'll notice that I commented out the libdrm purge, because that was breaking the desktop environment. Leaving it in and running without the desktop on a Lite OS gives the same failure messages. |
|
@pelwell You don't need / want to install Wayland at all. I use latest stable Wayland and an stable compositor, but that implies installing a LOT of other stuff (I can help with that, of course, but that's a different matter). |
|
@pelwell Sorry about my previous post: it seems that even if you are building Wayland, you have tested this on KMS/DRM. The errors you are seeing ( And also in config.txt comment out the line: Now try speaker-test. If speaker-test works, then SDLPoP (any SDL2 program) will work. |
|
Audio seems to be the least of my problems - key events aren't working; it's as if the SDL world is not connected to a keyboard or display. |
Create Or simply do everything as root (that was the very first step in my instructions :D) |
|
To save us both time, would you be able to upload an image somewhere that demonstrates the problem? |
|
Thank you. Installing that image boots to a console prompt as root. I can then run |
|
Then what's going on with my Raspberry Pi 4B? What a mistery. |
|
I don't have a 2GB model, but I've tried to emulate it with What do the following commands report? I'll ask around the office and try to match yours as closely as possible. |
|
tail -4 /proc/cpuinfo vcgencmd bootloader_version |
|
With your image running on B0 silicon with: and I still have no swiotlb errors. I'm sorry, but I'm going to shelve this investigation unless something new comes to light. |
|
@pelwell The error doesn't seem to harm the system stability or anything, but really, isn't this a very strange thing? Are there other differences between Rpi4 models besides RAM? I mean, you tried my image on a 2GB model, right? Other possible explanation would be the video mode in use, since video modes would use different RAM amounts. What resolution were you using when you tested my image? (Assuming you tested in on a 2GB Pi4) |
|
My test board is actually a 4GB unit, but with total_mem=2048 it should behave exactly like a 2GB unit. The display is a 4K DELL, but the frame buffer appears scaled. Can you post the output of: (assuming your monitor is plugged into HDMI0)? |
|
Sure: It's indeed connected to HDMI0. If you don't have a 2GB unit, I could send you one for debugging. I can't see any other difference. |
|
Thanks for the offer of a loan, but a colleague has lent me a 2GB 1.2 from his extensive collection: Using your EDID (saving it to /lib/firmware/edid and adding |
|
@pelwell Oh, well. Then there isn't anything else we can do. Thanks for your debugging efforts, really. I know how valuable time is. |
|
@pelwell Found what causes the errors on my Pi4 but not on yours, since Pi kernel 6.2.21.
If I unplug it, the errors are gone. If I plug it, errors appear when launching SDL2 games: |
|
Oh well done. I'll continue to look in that area as time allows. |
|
@pelwell The modules used by Logitech receivers (I have several and they all use the same) are: The errors only happen on the Raspberry Pi (let's not forget they are |
So I don't misunderstand you, can you confirm that without the receiver plugged in both the swiotlb and ioctl error messages disappear? |
|
without the receiver plugged in both the swiotlb and ioctl error messages disappear That is true. Plus: with NO logitech receiver connected, loading the modules manually and then running the game, the errors don't appear. Errors appear ONLY when receiver is connected and the modules are loaded. In fact, I can connect the receiver, unload the modules, and the errors DO appear. So the determining factor is the device being connected. |
|
And one more strange thing: the devices connected to the logitech receiver DO work after UNLOADING the modules But in that case, only half of the errors appear. So: With the DEVICE CONNECTED, and MODULES LOADED: In dmesg: With DEVICE CONNECTED, and modules UNLOADED: In dmesg: |
|
I don't believe it - with a Logitech wireless dongle (and mouse) I see exactly the same ioctl errors as you but the kernel message log is clean - no swiotlb warnings. Even running a memory stresser to randomly allocate most of the RAM doesn't change things. |
|
@pelwell Any other experiments I should do with this? Do you need more info? Did you find out something new? |
|
I stopped looking at this after trying and failing to recreate the swiotlb errors (which are definitely my field). I haven't investigate the ioctl() error messages. Is there any obvious malfunction? |
|
@pelwell No, everything seems to be working fine otherwise. |
@vanfanel Hi, I found a related issue on SDL side: libsdl-org/SDL#6799
and run SDL program with that env var $ sdl2-jstest --list
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Invalid argument
ioctl (GFEATURE): Invalid argument
ioctl (GFEATURE): Invalid argument
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
ioctl (GFEATURE): Broken pipe
No joysticks were found
$ env SDL_HIDAPI_IGNORE_DEVICES=0x046d/0x0000 sdl2-jstest --list
No joysticks were found
|
|
@detiam Ah, I guess it should be fixed on SDL's side then? |
|
Oh well, lsusb says this here: And if I do: I get no errors at all. Great! Let's PR this... |
|
Ok, this was fixed on the SDL2 side, so closing this. Thanks all involved! :) |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Using some SDL2 programs on MESA on KMS/DRM or Wayland, I see this on the TTY:
Which in dmesg means:
This started to happen somewhere between kernel 6.1.25-v8+ and kernel 6.1.34-v8+
A good game to reproduce this is SDLPoP:
https://github.com/NagyD/SDLPoP
I am using the
vc4-kms-v3dvideo overlay, and direct ALSA audio with the vc4hdmi audio device, and latest stable MESA 23.1.3Steps to reproduce the behaviour
Run and SDL2 program on KMS/DRM or Wayland (like SDLPoP: https://github.com/NagyD/SDLPoP) and look at console and dmesg.
Device (s)
Raspberry Pi 4 Mod. B
System
bullseye
Linux debian 6.1.34-v8+ #1657 SMP PREEMPT Fri Jun 16 12:36:29 BST 2023 aarch64 GNU/Linux
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: