N64 crashes after 10 min

Bobberella

Yeah. I have 3 Pies and they all glitch at 10 minutes. The 1.44Ghz one im working on is the fastest... possibly too fast.

The others are stable at 1.4Ghz. All you have to do is goid all of the warrenties. My GF has played more than 100 hours on each of the 1.4Ghz ones.

However... im getting this glitch so I started to tinker with the SDRAM. The 1.4Ghz ones will make it past the glitch and continue on but the 1.44Ghz one is a little more weird. Its the only pi i could boot at 1.75 GHz.

dankcushions

@bobberella said in N64 crashes after 10 min:

My GF has played more than 100 hours on each of the 1.4Ghz ones.

irrelevant unless that was n64. each emulator taxes the hardware in different ways.

like i said before, for us to get any meaningful bug reports we people to remove ALL their overclocks, use a stock image ideally, update to the latest mupen64plus via source, and see if the issue is still happening. also test with different videoplugins (gles2n64, etc).

If the issue happens to everyone with that scenario, then there's obviously some kind of issue in gliden64 (memory leak?) which can then be taken further. right now we have nothing.

quicksilver

@dankcushions I have tested at stock speeds and the glitch does still occur for me. It has only occurred using glide. It has never happened for me with the other plugins. When I have some time later today I will test using a fresh stock rpi image and will test mupen64-glide from binary and source.

Riverstorm

@dankcushions said in N64 crashes after 10 min:

irrelevant unless that was n64. each emulator taxes the hardware in different ways.

Agreed, did you get it to run at 1750MHz? I had an issue that went undetected for months. It only crashed in one scenario when installing packages. Buzz pointed out it might be worth looking at my overclock. When I did some "real" stress testing it was revealed my overclock settings were unstable.

Here's a great Overclock testing link. It takes time to get through all the tests but you can almost guarantee it's stable.

I think also I read somewhere where they had the Pi 3 SDRAM overclock settings in the raspi-config at 500MHz for Turbo but found occasional corruption on SD cards so they bumped it to 600MHz. I am guessing it was some correlation with the other settings.

At work when we have issues with firewalls we strip everything down to basically an all/all--any scenario in both directions with no AV, IPS, IDS, proxies, web filtering, SSL inspection, etc. all off. I think Dank is correct to strip it down. Your overclocks seems exceptional and potentially unstable. If it was a global problem more people would probably be reporting the issue.

It has only occurred using glide.

What game? I have a Pi setup I could run a test to see what happens here using Glide.

quicksilver

@riverstorm I personally have had it happen on diddy kong racing, battle tanx, road rash 64 and some others. Doesnt happen at a specific spot but seems to occur after about 10-20 mins of continuous gameplay. Basically what happens is the screen gets shaky and all the graphics get all jumbled up. I will try and post a pic next time it happens. I thought at one point I had the issue solved when I removed my pi from my nespi case but now the glitch still happens occasionally (though not as bad as before). Like I told DankCushions I will try a fresh stock image and test to see if I can get it to occur. Hopefully that will narrow down whats causing this.

Bobberella

"irrelevant unless that was n64. each emulator taxes the hardware in different ways."

@dankcushions It is N64... and I understand it may not be "stable" but if it doesnt crash then I wont worry.

"What game? I have a Pi setup I could run a test to see what happens here using Glide."

@Riverstorm Mario Party 2 & 3 so far are the issue.

=============
"SD cards so they bumped it to 600MHz"

Does anyone know why the over voltages on the SDRAM are always suggested to be setting to over_voltage_sdram - voltage of all SDRAM parts (c, i, and p) as (p=6,i= 4,c=4) and not ( (p=6,i= 6,c=6)? The literature says to set them all equally.

quicksilver

@bobberella stability is more than just crashes. Artifacting, and other signs of improper or undesired behavior are other signs of unstable overclocking. Playing around with an unstable overclock because it's "good enough" is asking for trouble. It can lead to SD card corruption and loss of data. Also for our purposes we need to find out what the root issue is and an overclocked pi adds way too many variables. If you are getting straight up freezes while playing games then I can bet 100% that your overclock is not stable. We don't want to confuse the issue here so it would be best to discuss results based on Pi's running at stock speeds.

Riverstorm

@bobberella said in N64 crashes after 10 min:

Does anyone know why the over voltages on the SDRAM are always suggested to be setting to over_voltage_sdram

Using over_voltage_sdram sets the SDRAM Controller, SDRAM I/O and SDRAM PHY (RAM Chip) all to the same value from 0.8 to 1.4v in 0.025 increments. The values are -16 to 8. The default 0 at 1.2v. I know bumping them [up] help in stability in overclocking RAM as well as sdram_schmoo when bumping the sdram frequency fairly high. Why they recommend setting the physical RAM chip at a higher voltage I don't know. I know the engineers on the Raspberry Pi forum would probably be able to split the hairs there. I used to use the separate values but now I just use over_voltage_sdram set to 2 for 1.25v with sdram_freq set to 600. I have overclocked the SD card as well and it seems to run stable.

I will test out a few of the game mentioned and see what happens.

Riverstorm

@quicksilver said in N64 crashes after 10 min:

Artifacting, and other signs of improper or undesired behavior are other signs of unstable overclocking.

I pushed the gpu_freq right up to seeing artifacts in ES and then backed down. It was running but not sure how stable. A stable overclock is really about time and tedium. Tweak, retest, tweak, retest, tweak, retest, tweak, retest...well a stable one at least! :)

quicksilver

@riverstorm I have found that quake 3 is a good resource for testing overclocks. I run all the automated tests that are recommended first like memtester and stress and if I get a passing grade then I test with quake 3 . Often times clock speeds that pass the automated tests fail miserably when put to a real world test like quake 3. Quake 3 works the GPU/CPU and RAM pretty hard. I found it to be more stressful than the individual tests and in most cases if your overclock is unstable the game will crash within a few minutes. However to verify my overclocks stability I will usually let the game run in first person spectator mode for 4-5 hrs at least. I have had quake 3 freeze after 1-2 hours if the overclock is unstable. So thorough testing is definitely needed when overclocking. I doubt most people test thoroughly enough and are running around with unstable overclocks.

Riverstorm

@quicksilver said in N64 crashes after 10 min:

I have found that quake 3 is a good resource for testing overclocks.

I have just base Quake III but not the expansions. Does that work for testing? Are the Docs sufficient to install it libretro-tyrquake? I do the same and let it run several hours too. This past weekend I hooked it to the TV and let it go all afternoon while I did some other work. The heat seems to creep up real slow right before it peaks so I let it run a good long time. I always try to share ambient when talking overclocking temps as it doesn't make much sense if you don't have a baseline to work from. Big difference if it's 15 or 25C in the room.

quicksilver

@riverstorm the freeware version of quake 3 should work fine. I believe it's listed as quake3 under optional packages. Easiest way to test is to load a skirmish, load a bunch of bots (8 seems a good number). Set kill count and time limit to 0. Once you get into the game press ~ key to open the console. Type /team spectator

Then press enter. Press ~ again to close the console. You are now spectating. Press the fire button and it will place you in a first person view of one of the bots. Now the game will run until you stop it or it crashes. Make sure you have good cooling because it will (as you noted) get your pi very warm. I am using a kintaro 9k case that has an awesome heatsink. For me the temp will climb to 69C and hover there indefinitely. Before i had that case I had a small heatsink and my pi would overheat within about 15 mins of quake 3.

Riverstorm

@quicksilver - Whew, I locked up within minutes running Quake III. I'll have to take another look at my settings as they are pretty modest. I didn't even break an arm_freq of 1300 but I suspect the GPU and RAM are more taxed with Q3.

quicksilver

@riverstorm I am going to start a separate thread on overclocking as we are veering off topic somewhat.

quicksilver

@dankcushions just setup a stock image on my spare SD card. Nothing on it except two N64 games. Within 10-20 minutes of playing battle tanx the graphics glitched out and the game froze. This is using mupen64-glide. Something is going on here.

quicksilver

Just happened again while playing Diddy Kong racing. I managed to get a picture this time. Again, stock retropie image. Happened about 10-20 mins into play time.

https://imgur.com/a/lgqGz

I will update Mupen64 from source and test again.

Edit: just updated from source. Same issue.

Bobberella

I can manage to get through the 10 minute glitch fairly easily with a lower SDRAM frequency than a higher one.

If you set SDRAM_freq to 550 and not something insanely high the Rpi 3 can sort itself out pretty well. If you set it to 600 or above then screen will get worse and worse and will it freezes.

I am currently matching my GPU and SDRAM overclock and it seems to help get thought the 15 minute glitch...

Here is a reddit post I found that seems to be the same issue.

https://www.google.ca/amp/s/amp.reddit.com/r/RetroPie/comments/7kvgq9/n64_games_graphical_errorsfreezing_my_pi_3_after/

quicksilver

@bobberella overclock isn't the root issue here. Read my earlier posting, I tried a stock image and the emulator is still glitching out and freezing. I'm wondering if it is somehow related to the framebuffer issue that the fps counter was supposed to solve.

EndersEnigma

@quicksilver @dankcushions

I did a fresh load from a brand new SD card with no overclock settings and updated from source, I am still getting the same 10-20 min crash time. I have even downloaded ROMs from different locations just inc case my ROM was corrupt, this does not seem to be the case. I have the EXACT same issues with varying levels of overclock (which I am not using any more as I continue to test issues per admin instruction).

It seems to be software related, but I am not sure what information the developers need to further look into this issue.

At this time I am using GLES when possible as it performs great (once you tweak the audio setting to allow save states). If the game does not run on GLES, RICE, or LR-, then I just cant play it because every game I have tested on GLIDE crashes at the 10-20 min mark. I use the spreadsheet on the n64 emulation page as a starting point to guide which emulator I run, but I have found that list is not up to date and its better to just experiment on my own. This is very frustrating as playing the same game up to 4 different times for 20 min to test for the "GLIDE glitch" as i have come to call it is painstakingly tedious.

SUMMARY:
I have found out that GLIDE crashes between 12-15 min on almost every game I have tried (about 12 games total). The problem happens only once at that time interval (does NOT repeat every 12-15 min after the first one). If i let the game sit at an idle point such as a load screen, save screen, or face my character into a wall or something, the game will blur and stutter for about 30-45 seconds then recovers and runs great, If I move at all or force the game to process movement of almost any kind it crashes. This is impossible on games like Aerofighters Assault where you are in constant motion, these types of games crash every time as a result. The indicator if the game has crashed or not is tied to audio output. So long as sound is playing normally when the problem starts, it is in the "blur" phase and recovers within 30-45 seconds every time. If you try to move or jump or cycle through a menu during the "blur", the sound will cut out completely or hang on a note and sustain until you hard reset.

I hope this helps, I am happy to provide any additional information if it assists in solving this issue.

quicksilver

@endersenigma I see you have spent as much time trying to figure this out as I have. I've noticed all the strange nuances with this glitch as well. I suspect this is an issue with mupen64-glide on the pi itself. If this issue was universal to all devices I'm sure the mupen64 devs would already know about it. At this point I just need to figure out who to report it to.