Weird problem with screen not being cleared

[ariath]

I'm using a RPi 3 with DietPi.

I have noticed that the screen don't get cleared when you resume the emulation, as there are chunks of the config GUI around the screen.

I have experienced another strange bug: If i configure the autostart config to not use the GUI, when i try to exit the emulator the systemd-journald process starts eating the 99% of the CPU and i cannot exit the emulator unless i open another console and kill the systemd-journald process.

Then, if i execute "journalctl -r", i get a lot of entries like these ones:

bash[101]: IP: 0x76ece624 [e5820000] 0xa7804664
bash[101]: processed: 0x76ece620

As i said, this only happens when i quit the emulator after the autostart config was autoloaded.

See ya!

[midwan]

Strange, I haven't seen any such problems so far. I usually have the emulator running without GUI also, but I can quit it normally (there is a slight delay of a few seconds sometimes, until the audio thread is terminated, but it will exit cleanly).

Are you on the latest DietPi (v130)?

[Fourdee]

@ariath

Thanks for the report.

Could you please send us a bug report? I'd like to check your current installation and settings.
Please follow the steps here to send a bug report: http://dietpi.com/phpbb/viewtopic.php?f=8&t=499#p2184

@midwan
I'll run some tests and see if I can replicate this issue on my RPi 3.

[ariath]

Sure i can! :)

Only one question: Do i have to run dietpi-bugreport after or before killing the systemd-journald process?

See ya and thanks for the quick response! :)

P.D: I'm using this DietPi version: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-%28Jessie%29.7z . But the uae4arm im using is the midwan one.

[Fourdee]

@ariath

Do i have to run dietpi-bugreport after or before killing the systemd-journald process?

After please, but dont kill the systemd-journald process until after the bug report is sent.

[Fourdee]

My tests:

• DietPi-AmiBerry image
• RPi 3

I have noticed that the screen don't get cleared when you resume the emulation, as there are chunks of the config GUI around the screen.

Unable to replicate when using either autostart method:

• uae4arm fast boot
• uae4arm standard boot

I have experienced another strange bug: If i configure the autostart config to not use the GUI, when i try to exit the emulator the systemd-journald process starts eating the 99% of the CPU and i cannot exit the emulator unless i open another console and kill the systemd-journald process.

Unable to replicate with use_gui=no

@ariath Some questions while we wait for bug report:

• Did you install AmiBerry with the DietPi-ArmBerry image, or a standard DietPi image from http://dietpi.com/download ?
• Have you made any manual changes to the system configuration files you can remember (minus the autostart.uae)?
• Have you installed any other software on the device, either via DietPi-Software or apt-get?

[ariath]

This the bugreport reference code: eaf73419-df52-422e-830a-bca42c70c495-0 .

I used the DietPi-AmiBerry image from here: http://blitterstudio.com/amiberry/ (the one in the installation step).

The only additional software i remember have installed is ProFTP (from DietPi-Software) and the required ones to download and build uae4arm (gcc, make, git, etc ...).

I remember that the uae4arm config i'm using is one i copied from my Android tablet, and the only changes i did in the system are the required ones to configure the WiFi and Bluetooth.

See ya!

P.D: What i see really strange is that the emulator exits just fine if i use use_gui=yes. I only get this behaviour when i use use_gui=no :S.
Amiga 500.txt

P.D 2: I include the config i'm using for the emulator (autostart is currently a symbolic link to this config)

P.D 3: BTW, what does this lines could mean? :S
bash[101]: IP: 0x76ece624 [e5820000] 0xa7804664
bash[101]: processed: 0x76ece620

[Fourdee]

@ariath

eaf73419-df52-422e-830a-bca42c70c495-0

Excellent, i'll take a look 👍

I remember that the uae4arm config i'm using is one i copied from my Android tablet

Thats most likely the cause. But i'll run some tests to confirm.

Edit: Would you be able to upload your android autostart.uae and post it here?

[ariath]

It is the Amiga 500.txt that i attached in the previous post :) .

What i did was:

1. I copied the config from my Android tablet to the Pi.
2. Then i fixed the file paths.
3. Next i renamed the original autostart.uae in Pi
4. And last, i made a symbolic link from the Amiga 500.uae to the autostart.uae.

See ya!

[Fourdee]

@ariath
Thanks. I'll run some tests.

Diff check: https://www.diffchecker.com/fJQnDH5S

• Left = AmiBerry default config
• Right = @ariath

[Fourdee]

I have noticed that the screen don't get cleared when you resume the emulation, as there are chunks of the config GUI around the screen.

Replicated | Uae4arm menu remains visible under xinit with gfx_correct_aspect=0

• @midwan Only occurs when running uae4arm-rpi under xinit and gfx_correct_aspect=0.
• @ariath Recommend changing: gfx_correct_aspect=0 for the time being. Or edit /etc/uae4arm-rpi/uae4arm-rpi_run.sh and remove the xinit word.

99% of the CPU and i cannot exit the emulator unless i open another console and kill the systemd-journald process.

Still cant replicate with your config and symlink. Runs fine for me:

root@DietPi:/etc/uae4arm-rpi/conf# ls -lha
total 24K
drwxr-xr-x 2 root root 4.0K Sep 14 18:02 .
drwxr-xr-x 9 root root 4.0K Sep 14 18:01 ..
-rwxr-xr-x 1 root root  211 Sep 14 18:01 adfdir.conf
-rw-r--r-- 1 root root 7.6K Sep 14 18:02 amiga.uae
lrwxrwxrwx 1 root root    9 Sep 14 18:02 autostart.uae -> amiga.uae
-rwxr-xr-x 1 root root   45 Sep 14 18:01 dir.txt

I'll dig into your bug report a bit more.

[Fourdee]

@ariath
Strange, missing /etc configurations from the bug report. Can you run the following and paste results please:

df -h
ls -lha /

[midwan]

Thanks for the confirmation, I'll look into this.

[ariath]

After some testing, i think xinit was the problem.

I removed it from the script and, not only the screen is now clear after resuming the emulation, but the emulator finally exits correctly .

Anyways, here is the requested info:

root@AmigaPi:~# df -h
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/root 15G 1011M 14G 7% /
devtmpfs 427M 0 427M 0% /dev
tmpfs 432M 0 432M 0% /dev/shm
tmpfs 432M 5,9M 426M 2% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 432M 0 432M 0% /sys/fs/cgroup
tmpfs 10M 1,2M 8,9M 12% /DietPi
tmpfs 20M 36K 20M 1% /var/log
tmpfs 432M 4,0K 432M 1% /tmp
/dev/mmcblk0p1 60M 23M 38M 37% /boot

root@AmigaPi:~# ls -lha /
total 84K
drwxr-xr-x 21 root root 4,0K sep 13 10:45 .
drwxr-xr-x 21 root root 4,0K sep 13 10:45 ..
drwxr-xr-x 2 root root 4,0K jun 17 13:44 bin
drwxr-xr-x 5 root root 16K ene 1 1970 boot
drwxr-xr-x 14 root root 3,3K sep 14 15:22 dev
drwxrwxrwt 3 root root 120 sep 14 15:22 DietPi
drwxr-xr-x 79 root root 4,0K sep 13 15:45 etc
drwxr-xr-x 18 root root 4,0K jun 17 16:56 lib
drwxr-xr-x 4 root root 4,0K sep 13 11:25 logfile_storage
drwx------ 2 root root 16K feb 26 2016 lost+found
drwxr-xr-x 6 root root 4,0K sep 7 13:38 mnt
drwxr-xr-x 3 root root 4,0K feb 26 2016 opt
dr-xr-xr-x 129 root root 0 ene 1 1970 proc
drwx------ 6 root root 4,0K sep 13 11:45 root
drwxr-xr-x 16 root root 580 sep 14 15:23 run
drwxr-xr-x 2 root root 4,0K jun 17 13:44 sbin
drwxr-xr-x 3 root root 4,0K sep 13 10:42 srv
dr-xr-xr-x 12 root root 0 ene 1 1970 sys
drwxrwxrwt 8 root root 180 sep 14 19:18 tmp
drwxr-xr-x 10 root root 4,0K feb 26 2016 usr
drwxr-xr-x 11 root root 4,0K sep 7 13:27 var

But, doing some testing, i have another "bug" (seems to be ALSA audio):

sep 14 19:25:07 AmigaPi systemd[1]: Unit uae4arm-rpi.service entered failed state.
sep 14 19:25:07 AmigaPi systemd[1]: uae4arm-rpi.service: main process exited, code=exited, status=137/n/a
sep 14 19:25:07 AmigaPi bash[1534]: uae4arm-rpi_run.sh: línea 14: 1539 Terminado (killed) ./uae4arm-rpi_github -f conf/autostart.uae
sep 14 19:23:54 AmigaPi bash[1534]: ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
sep 14 19:23:51 AmigaPi systemd[1]: Started AmiBerry (uae4ARM) Amiga Emulator.
sep 14 19:23:51 AmigaPi systemd[1]: Starting AmiBerry (uae4ARM) Amiga Emulator...

This happens when i navigate through the GUI with the keyboard arrows.
When i reach the Quit button (without pressing Space), all seems to freeze, the keyboard and the mouse are unresponsive.

But i can open a terminal from SSH and kill the processes with htop, so, only the emulator, or the X session, is freezing.

See ya!

[midwan]

The system is configured to run it as a service, so if it detects it has stopped it will try to re-run it automatically. If you want to start it manually, you should disable the service with:
systemctl disable uae4arm-rpi

[ariath]

No, it is okay this way, i want the emulator to boot with the Pi :).

But, what about this line?
sep 14 19:23:54 AmigaPi bash[1534]: ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

Also, i wonder... why the default script runs the emulator with xinit if it is not required?
There is any advantage using xinit? :S

See ya!

[Fourdee]

@ariath

sep 14 19:23:54 AmigaPi bash[1534]: ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

Looks like a ALSA buffer underrun. Which is strange because i believe your cachesize=8192 is a 8192 audio buffer size for uae4arm-rpi. Thats large and shouldn't be causing a underrun.

Try running Uae4arm at a higher priority:

• When uae4arm is running
• dietpi-process_tool
• Select uae4arm
• Change nice to something like -5

You could even try scheduler FIFO (high priority, similar to realtime), but, its untested with uae4arm.

I removed it from the script and, not only the screen is now clear after resuming the emulation, but the emulator finally exits correctly .

Excellent 👍 And thanks for pasting those results.

Also, i wonder... why the default script runs the emulator with xinit if it is not required?
There is any advantage using xinit? :S

I believe this was a added to fix an issue with keyboard LEDS on 1st release: https://github.com/Fourdee/DietPi/issues/474#issuecomment-243847858

[midwan]

@ariath
The ALSA buffer underrun is a known issue with all versions of UAE4Arm currently (even in the original Chips-fr version). I haven't had time to fix it yet, I did spend a few hours poking around but didn't manage to find a solution.

The cachesize=8192 is probably the JIT cache, not the audio buffer. :) Also, it's probably obsolete since the emulator uses a fixed number internally (8192) anyway, and doesn't use the config value at all. It's there for config compatibility reasons with WinUAE.

If the suggestion to run UAE at a higher priority does help the underrun issue, I'd be grateful if you could tell us so.

Finally, the xinit was added to get proper support for the Caps Lock key, since it didn't seem to work when started from the console, as @Fourdee mentioned. This is also something that will be fixed eventually.

[ariath]

I have tried setting the emulator priority to -5, but, as soon i navigate with the keyboard keys to the Quit button, it freezes.

But... this time, i didn't get any ALSA error message :S.

What i wonder is... why this happens only with the Quit button, and, why only happens when i use the keyboard cursor keys to select the control?

When i use the mouse all goes fine :S.

See ya!

P.D: Well, i think i was wrong. The emulator don't freezes upon selecting the Quit button.
I have tested setting the cursor on the Reset button, but this time i clicked the left cursor button (the Quit button is to the right), and the emulator freezed :P .

[midwan]

@ariath I didn't have time to test this one yet, so bear with me... :)

• Does it happen only when using the keyboard to navigate? (I assumed so from your report, but just to clarify)
• Assuming the above is true, does it happen in one specific area only? If so, which one?
• Could you give me specific steps to recreate this please?

[ariath]

No problem, i was also quite busy yerterday XD.

I have done some tests today, and i have found a couple of places where the emulator freezes (basically, its CPU usage goes to 99%): Miscellaneus tab, Input tab and the Reset button.

All you have to try is to navigate with the cursor keys.
For example: When the emulator starts, the cursor (the blue rectangle) is set at the Configurations tab. Then, i go all the way down until i reach the Reset button.

Is then when, if i try to navigate left or right (i repeat, the cursor si currently over the Reset button), the emulator freezes.

At the Input tab, i have noticed the freeze at the mouse sensivity slider, and in the Miscellaneus one, going down through the check boxes.

I wonder if the problem would happen with a gamepad also. I have a sixaxis, but i haven't tried to pair it with the Pi yet :S.

See ya!

P.D: Also, the resolution sliders have a slight problem: If you slide them to the right, they are fine, but... if you try to slide them to the left... the cursor go back to the section tabs :P.

P.D 2: And yes, i only have problems with the keyboard. I have not experienced any problem with the mouse.

[midwan]

@ariath Thanks for that detailed report, I will test it out and see.
If we can recreate this, I already have an idea of where it might be coming from. ;)

[Fourdee]

@midwan

Curious more than anything.
When the Uae4arm menu is running (not started emulation), CPU usage is around 77%. Is the main/render loop running as a "as fast as it can go" or "framerate cap/vsync"?:

Xinit also chewing up CPU, without Xinit below:

[midwan]

@Fourdee Thanks for that extra info, I'll take a look. It's probably running in a loop waiting to detect any input events, and updating the UI on VSync.

[midwan]

Confirmed - Emulator GUI freezes when navigating with keyboard, if you are on the Reset button and press Left/Right keys.

Also, 100% CPU usage in GUI, even without it actually doing anything.

I'll get it fixed.

[midwan]

The latest commit fixes the navigation issues.

I'll see what we can do about the high CPU usage in the GUI.

[ariath]

There are 2 more places where i have noticed freezes:

Miscellaneus tab: There are 3 checkboxes and two another controls below them (as i remember). The emulator freezes when the cursor is placed at the last checkbox and and you press down to go to the other two controls.

Input tab: The freeze happens at the mouse sensivity slider.

See ya!

[midwan]

@ariath Thanks for reporting these, I'll get it fixed!

[midwan]

I've added a fix for the GUI getting stuck there, I will also add the possibility to go down to the Numlock LED and ScrollLock LED options as the next step (those controls are new so the navigation would not go there).