Overclocking

[hojnikb]

Sounds reasonable. It's on my list.

Many thanks in advance!

Great. Now i will be able to squeeze magical 1.2Ghz from my Pi without actually running at this freq all the time

As for the sdcard curruption; today when i OC it to 1.1Ghz to compile something, when i made apt-get, some of the files linked with apt got currupted (never happend before when was on 930 with no overvolt).Thankfully files could be easily replaced, so it was not a big deal.
edit:
this was with raspbian default repo kernel/fw, not the latest one from rpi-update

So if i get this currupion thing correctly: when Pi is overclocked, becouse arm freq is changed and some timing is different, this somehow messes acces to sd card, is that correct ?

Could the issue be in the sdcard driver itself or is that not the problem (afaik driver was the issue back then when cards were really slow) ?

[milhouse]

@dom - I use a simple script (which you can see here) that runs every few seconds, and displays various outputs from vcgencmd such as current ARM/Core/H264 frequency, Core Temp etc. - ie. the vcgencmd command is executed a large number of times during any given period - so my question is: is there any way this vcgencmd activity could interfere with the operation of the arm or core etc., and result in some sort of corruption? I'm pretty sure the answer is "no", but just wanted to check...

I've struggled to identify any correlation between corruption/instability and the running of this script (which I've left to run for over 24 hours without any problem) but the merest possibility of it existing is starting to prey on my mind!

[Licaon_Kter]

...
Possibly some Pi boards (specifically the 2835 SoC) are not succeptable to this problem.
...

Don't they all have the same SoC anyway?

BTW, I've have been using:

Code: Select all

arm:850
core:450
v3d/isp/h264:300
sdram:450
no overvolt

BUT NEVER getting a corrupted card, and even when trying some OC options that lock/restart the Pi like sdram >450 or arm>850 everything was in place after a restart.Was I just lucky? ( this card: http://www.raspberrypi.org/phpBB3/viewt ... 24#p166624 )

Here is my OC procedure:
*use the 192/64 mem split
*edit config.txt with your OC values of choice
*reboot
*get my q3 demos: http://www.sendspace.com/file/i91m1o and put them both in /home/pi/.q3a/baseq3/demos/ ( if the game does not see them maybe you need to put them in /root/.q3a/baseq3/demos/ too )
*start quake3
*console -> timedemo 1
*demo dema-1, wait for it to finish (<120sec), if it has not crashed, continue
*demo dema-2, wait for it to finish (<360sec), if it has not crashed, continue

looks ok, BUT, here's the thing, try something else
*quit quake3
*open TTY2, run stress --cpu 1 --vm 2 --vm-bytes 32M ( run sudo apt-get install stress if you don't have this program ) this will stress the CPU/MEM in the background but will leave the flimsy SD card alone
*switch back to TTY1 and run quake3
*console -> timedemo 1
*demo dema-1, wait for it to finish (more than 120sec), if it has not crashed, continue
*demo dema-2, wait for it to finish (more than 360sec), if it has not crashed, you might be ok
*quit quake3
*switch back to TTY2 and hit CTRL+C to stop stress
*repeat from start with bigger OC values

If you are still running ok after passing these I believe you got a good OC, in my testing it happened numerous times, I could pass the normal demos, or even lower, pass demo1, but not demo2, or pass both and crash when using stress at the same time, so while pushing 1GHz in TTY1 looks like a good OC if you did not pass these quake3 tests I believe it's just a disaster waiting to happen the next time your system gets a bit of work to do.

A bit of info on the demos:
*yes it's me playing after I got quake3 compiled, I'm rusty
*yes they're made in the DEMO version ( do PM me if you want to upload my build if you don't have it )
*I had to record them as the so called "four" demo never run on my system
*yes I misspelled the names to DEMA-1/2 and use them like that
*the first one has me and 3 other bots, it will use a lot of CPU at ~27fps average for the non-OC freqs (1920x1200, all high, 32bit framebuffer)
*the second one has me and 1 other bot, it will do a lot of fps ~38fps (1920x1200, all high, 32bit framebuffer) average for the non-OC freqs, there's a moment of seemingly pause as I fiddle with my controls, do wait, it ends at 9-3 for the bot, look in the lower right corner for the score, surprisingly this map was crashing ON LOAD when using some OC values that were passing the first demo with ease, and this got me thinking

[Dilligaf]

Yeah, but the quake 3 demos and stress don't do many writes to the card, I think it's multiple writes that are causing the issues. With xbmc I can do whatever in it and have no problems, do a library scan and it corrupts the card

[dom]

I've struggled to identify any correlation between corruption/instability and the running of this script (which I've left to run for over 24 hours without any problem) but the merest possibility of it existing is starting to prey on my mind!

Hmmmm. It's unlikely but not inconceivable. It could be worth disabling and see if anything behaves better.

[Licaon_Kter]

Yeah, but the quake 3 demos and stress don't do many writes to the card, I think it's multiple writes that are causing the issues. With xbmc I can do whatever in it and have no problems, do a library scan and it corrupts the card

Yes and no, before trying to asses the influence on the SD card part of the Pi shouldn't you assure a proper tested stable OC?
Having an unstable OC would yield all sorts of problems... exactly, just because XBMC might not load the Pi (both CPU and MEM wise) enough to expose such instability it does not mean it's not there, and when it tries to access the card, allocate buffers, whatever... bang... instability... corruption etc

BTW, stress has IO options too if that strikes your fancy, I did not use them as the SD cards are the weakest link in the hardware chain (expensive and fragile).

[kevs3d]

Hi, I've done quite a bit of testing with this last night. And for me - It's ALL about core frequency.

I can run reliably with my Transcend class 10 card with these settings:

Code: Select all

force_turbo=1
current_limit_override=0x5A000020
over_voltage=8
arm_freq=1100
sdram_freq=400
core_freq=250

Perform the usual CPU stress tests, quake3 and card writes - no issues.

As soon as I raise the core freq it all gets a bit wobbly - /boot corruption and/or kernel fail to init on startup.

Even core 300 is enough for it to get into a corrupted state.

With the class 4 card (Kingston) this does not happen - I can run core 500 with those same settings above.

For my setup certainly, this makes me confident the core settings are causing the problems - obviously since that's tied to so much other stuff, I'm not sure how much it helps

I will try keeping arm@700 next and raise the core just by itself to see if that can corrupt it also.

Cheers,

Kev

[Tompen]

Found a backup of my working xbian install from 9 sep, restored to this SD-card. Same problem, corruption with core_freq=300 and also with core_freq=310. Will try lots of older start.elf and kernels to understand if I can find any combination that works.

[sumolx]

My setup:

Code: Select all

SD Card:  SanDisk videoHD 8 GByte Class 4 Card
Image:    r12014.img.zip	27-Sep-2012 15:02	 83M

Rock solid with the following:

Code: Select all

boot_delay=1
force_turbo=1
over_voltage=4
arm_freq=900
gpu_freq=333
core_freq=500
sdram_freq=500

Now if I increase over_voltage=6 then the EXT4 partition becomes corrupted. I was increasing the voltage in order to achieve a stable arm_freq=1000. I had then reverted back to my original setting arm_freq=900 but I forgot to revert over_voltage=4, finding this would cause corruption. So I'm staying away from over_voltage=6 for now.

On a side note I am back-feeding Apple's 1 amp iPhone power supply to the lower USB port with using an A to A cable. This guarantees a 4.85v across TP1 and TP2 with Ethernet plugged in. Using the same power supply and trying many different Micro USB cables I could only achieve 4.20v ~ 4.35v which would cause all sorts of havoc.

[kevs3d]

Just a confirmation from further testing with these values:

Code: Select all

arm_freq=1100
core_freq=250
gpu_freq=333
sdram_freq=400
over_voltage=8
force_turbo=1
current_limit_override=0x5A000020

Rock solid in all tests for me - including a full apt-get update/upgrade + rpi-update (which always killed it before!) Raise core to 300 and BOOM - corruption almost immediately.

And with these settings, note only the core is overclocked - will corrupt the card (seems ok with core<500 with default arm speed)

Code: Select all

arm_freq=700
core_freq=500

So I'm going with raising core_freq as the definitive killer for my class 10 card!

Is there any way to disconnect the arm caches and SD card timings from the core? i.e. so we can still overclock the caches (which makes a big difference on many tests, including quake3) - but leave the SD card out of the fun? Yep, I have no idea what I'm talking about but I'm at least happy I can overclock to ARM 1100Mhz and GPU 333Mhz as long as I leave the core alone!

Kev

[Tompen]

I can consistenly reproduce data corruption with core_freq=300.
Without core_freq=300 it works OK. Because it is easy for me to do, I made some test.

I did the below tests 3 times, with identical result.

Booted wihout overclocked core_freq, wget my 88MB testfile.
change to core_freq=300 and reboot, then tar -xvf the file I had download. It works ok. Integrity of files written is questionable. My point is, it reads the file OK, tar -xvf does not detect corruption.

My other test:
Booted without overclocking core_freq. wget my 88MB testfile, twice. Reboot. Diff the downloaded files, no difference (as expected). Change to core_freq=300, reboot. diff the files, no difference. This is proof data is not getting corrupted during reads from SD-card.

While overclocked, transfer these two files to a ftp server. On ftp server, I diff the files. no difference.
This is proof data does not corrupt while being read from SD-card. It is proof data does not corrupt while transfer on LAN.

while overclocked, copy the file. Then reboot (to empty filecache in RAM).
diff the orginal file with the copied file. They differ.
This is proof data gets corrupted when it is being written to SD-card.

[Tompen]

A progress report from my testing

This works, I do not get corruption with core_freq=300 (all other settings kept the same, maybe my config.txt options do not exist in this older release, but I just keep them anyway)

works OK:
commit 43b688a2
Add sync_after_dma module parameter to kernel.
root@XBian:~# uname -a
Linux XBian 3.1.9+ #171 PREEMPT Tue Jul 17 01:08:22 BST 2012 armv6l GNU/Linux
root@XBian:~# /opt/vc/bin/vcgencmd version
Jul 17 2012 01:25:40
Copyright (c) 2012 Broadcom
version 325699 (release)

and to be certain, I tested also 8e981b6b and it also works without corruption in my test.

But the below and newer does not work, I get corruption with core_freq=300:
0d88fba0
Date: Thu Jul 26 00:50:08 2012 +0100
Trim the firmware builds. Add a smaller arm240_start.elf
root@XBian:~# uname -a
Linux XBian 3.1.9+ #202 PREEMPT Wed Jul 25 22:11:06 BST 2012 armv6l GNU/Linux
root@XBian:~# /opt/vc/bin/vcgencmd version
Jul 26 2012 00:48:29
Copyright (c) 2012 Broadcom
version 327550 (release)

I have no way of verifying that core_freq=300 actually sets something in the july releases because
vcgencmd measure_clock core
does not exist.

I will continue to reduce the scope, narrow it down further.
When I am certain, I will post here again. I have only tested once for the commits I have tried so far. But since my corruption does not seem intermittent, I hope the above is accurate.

[dom]

I will continue to reduce the scope, narrow it down further.
When I am certain, I will post here again. I have only tested once for the commits I have tried so far. But since my corruption does not seem intermittent, I hope the above is accurate.

This is useful. If you can confirm a single file change by a single revision, then I can hopefully identify the change. I'm assuming it is just start.elf that matters, not kernel.img.
Does that tie up with what you are seeing?

[Tompen]

Yes, I understand. Have not tried single file replace, I am replacing all files in /boot except cmdline.txt and config.txt. My goal is to find the revision that breaks it (hopefully). Then I will try isolate to single file (hopefully). But from past experience, data corruption is very elusive to figure out. Have been doing the same on other product a few years ago, and thought I was on the right track, but then realised I was wrong. A few days later I thought I was on another track that was right, and at that time I found it. Nothing is certain until it is certain.... It needs a lot of patience and even more testing.

[pmk]

Yes, I understand. Have not tried single file replace, I am replacing all files in /boot except cmdline.txt and config.txt. My goal is to find the revision that breaks it (hopefully). Then I will try isolate to single file (hopefully). But from past experience, data corruption is very elusive to figure out. Have been doing the same on other product a few years ago, and thought I was on the right track, but then realised I was wrong. A few days later I thought I was on another track that was right, and at that time I found it. Nothing is certain until it is certain.... It needs a lot of patience and even more testing.

If you can provide the files and a procedure I am free to do some testing on Sunday .......

[Kekule]

I could be way off base, but from my understanding the core_freq configuration effects the L2 cache frequency. Could this all be related to some issue with the cache?

[sumolx]

Ok.. I have been experimenting some more and I am able to achieve a rock solid overclock with the following settings. Viewing XBMC System -> Status -> Video or Hardware: My temp reached 83C

Code: Select all

arm_freq=1000
gpu_freq=333
core_freq=500
sdram_freq=500
over_voltage=8
force_turbo=1
current_limit_override=0x5A000020

Now i was able to corrupt my card by forcing these additional settings:

Code: Select all

h264_freq=333
isp_freq=333
v3d_freq=333

I'm thinking it's not v3d_freq=333 due to the reason I was seeing this clock speed being enforced with only gpu_freq=333 being specified. I was measuring v3d by using command: "vcgencmd measure_clock v3d" and it would report 333.

However, h264 and isp always reported 250 during playback of a sample mkv and thats why I decided to try and enforce those values manually. At that point my card became corrupt during boot up.

Quick question with my settings if I hit 85C with force_turbo=1 will it automatically down clock arm, gpu and core until the temps are safe again?

[Twigs]

some testing on my pi;
I can do
arm_freq=1000, core_freq=500, sdram_freq=500, over_voltage=4 with no issues
however
arm_freq=1000, core_freq=500, sdram_freq=500, over_voltage=6 causes final write errors and corruption - too much over voltage?

or

If i leave out the core_freq, I can wind it up to
arm_freq=1200, sdram_freq=600, over_voltage=12, over_voltage_sdram=4 with no issues
however
arm_freq=1200, sdram_freq=600, over_voltage=12, over_voltage_sdram=4, core_freq=400 causes final write errors and corruption.

The only way for me to get the core_freq higher than default is to start winding back arm_freq and voltages. It feels like there is a finite amount of "power" and that i can push it all to the arm and sdram or share some with the core. Is there any chance that there is literally a drop in voltage when pushing the overclock limits that is starving the sd card of power?

class 4 8GB sd card
Powered from psp charger hooked to gpio pins
voltage at the 5v power capacitor;
Idle 5.02v
100% cpu 5.00v (running "openssl speed")
never seen it below 4.99v
cpu is cooled and has never gotten above 46c
force_turbo=1
current_limit_override=0x5A000020

I will try testing some 3.3v traces tomorrow.
good night

[dom]

Now i was able to corrupt my card by forcing these additional settings:

Code: Select all

h264_freq=333
isp_freq=333
v3d_freq=333

I'll check the code, but those settings should have no effect (gpu_freq already did that)

Quick question with my settings if I hit 85C with force_turbo=1 will it automatically down clock arm, gpu and core until the temps are safe again?

Yes

[dom]

I will try testing some 3.3v traces tomorrow.
good night

It could be a voltage drop, but I would have expected that to be seen that on the 5V rail.
3.3V is used for the sdcard I/O, so a drop there could affect sdcard.

[dom]

I could be way off base, but from my understanding the core_freq configuration effects the L2 cache frequency. Could this all be related to some issue with the cache?

The L2 cache is always used, so this doesn't explain users with sdcard corruption running reliably from USB/nfs.

[Dietmar]

Hi all,
I can confirm the crash of my Sandisk 8 GB extreme card, using the Turbo Mode from configurations tool,
during the compiling of Qemu, brrr .

But with the settings

Code: Select all

arm_freq=1000
gpu_freq=333
core_freq=500
sdram_freq=500
over_voltage=8
force_turbo=1
current_limit_override=0x5A000020

all works fine ,
greetings Dietmar

[milhouse]

@dom: If you are unable to reproduce this corruption, I'll happily post you my board that fails at 750/255/+3 if the Foundation can send me a replacement in return (preferably one that hits 1200 with no over volting... only kidding).

I'm in the UK. Will even throw in a Transcend Class 10!

[dom]

@dom: If you are unable to reproduce this corruption, I'll happily post you my board that fails at 750/255/+3 if the Foundation can send me a replacement in return (preferably one that hits 1200 with no over volting... only kidding).

Thanks for offer, but I'm still feeling your failure case isn't the typical one.
I think if Tompen (or others) can identify that a github commit that causes the corruption, that's the most promising avenue.

[Tompen]

For me, the corruptions get introduced in this commit:
c2c114a0
Fix for 'Failed to add service' try two
# uname -a
Linux XBian 3.1.9+ #202 PREEMPT Wed Jul 25 22:11:06 BST 2012 armv6l GNU/Linux
# /opt/vc/bin/vcgencmd version
Jul 28 2012 02:53:14
Copyright (c) 2012 Broadcom
version 328039 (release)

I know this does not match my previous post. I can not explain that. Because results from my testing did not make sense, I went back and tested 0d88fba0 several times and it works OK. I must have either done that test wrong the first time when I got corruption, or my notes was wrong. I spent hours on 0d88fba0 and I can not get corruption with 0d88fba0.

My testing results are consistent. That is: They are not intermittent. The only exception I have had is the 0d88fba0, that is why I believe some error was made on my part in the first test on that commit.

I am confident in the above, but to make absolutely sure, I will do som further tests with a couple of older revisions to try and get corruption any way I can think of.

I have now done my wget && tar-xvf test three times (switching up and down between revisions) with same result:
With c2c114a0 I get corruption directly (but only with core_freq=300, without corefreq=300 it works OK). With d535b28c those same tests pass without problem both with and without core_freq=300.

After this round of stress testing on d535b28c that is needed + a couple of older revisions, I will start isolating indvidiual files. If it start.elf or kernel.