Overclocking

[wallarug]

What is the warranty 'bit'?

basically overvolting triggers it

how does cpu_freq avoid such from happening?

[Licaon_Kter]

how does cpu_freq avoid such from happening?

overvolting is a user choice, it's activated in the config.txt
cpu_freq only switches freqs between standard (700) and your OC choice, only, it does not do any auto-over-volting IF you did not set it to in the config.txt

[dom]

basically overvolting triggers it

You are allowed to overvolt if done through raspi-config which uses the cpufreq driver.
Manually adding "force_turbo=1" to config.txt, when over_voltage>0 will override the cpufreq driver and sets your warranty bit.

[wallarug]

basically overvolting triggers it

You are allowed to overvolt if done through raspi-config which uses the cpufreq driver.
Manually adding "force_turbo=1" to config.txt, when over_voltage>0 will override the cpufreq driver and sets your warranty bit.

That's great info!

How can you tell if your warranty is voided? Is there a command or would they just check it at the factory?

[milhouse]

How can you tell if your warranty is voided? Is there a command or would they just check it at the factory?

Code: Select all

cat /proc/cpuinfo

Look at your Revision code - if it starts with a 1, you've set the warranty bit (and your warranty is void).

[wallarug]

How can you tell if your warranty is voided? Is there a command or would they just check it at the factory?

Code: Select all

cat /proc/cpuinfo

Look at your Revision code - if it starts with a 1, you've set the warranty bit (and your warranty is void).

Thanks, This is really helpful.

[TikkenBaxter]

Sad to inform, but these settings did corrupt my card after 1 week:
current_limit_override=0x5A000020
over_voltage_sdram=5
over_voltage=4
force_turbo=1
arm_freq=1026
sdram_freq=500

Happend to someone else?
Is there a even more safe overclock settings I could try?

[wallarug]

Is there a even more safe overclock settings I could try?

Try lowering the settings. That works for most people.

[dom]

@Tompen @portets (and others)

Can you please try (in config.txt)

Code: Select all

init_emmc_clock=100000000

and in cmdline.txt

Code: Select all

sdhci-bcm2708.emmc_clock_freq=100000000

and let me know if the corruption has gone, and whether

Code: Select all

sudo hdparm -t /dev/mmcblk0

gives the expected result.

This should work with existing kernels.

[milhouse]

@Tompen @portets (and others)

Can you please try (in config.txt)

Code: Select all

init_emmc_clock=100000000

and in cmdline.txt

Code: Select all

sdhci-bcm2708.emmc_clock_freq=100000000

Tested with:

Code: Select all

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #238 PREEMPT Fri Oct 5 23:19:10 BST 2012 armv6l GNU/Linux

pi@raspberrypi ~ $ vcgencmd version
Oct  6 2012 15:41:08
Copyright (c) 2012 Broadcom
version 342154 (release)

and with the addition of these cmdline.txt/config.txt changes, I still get corruption with 750/255/+3 overclock (granted, you think I'm obviously "special", but I've no idea why!)

I had the following output in syslog when performing a simple "dd if=/dev/zero of=./test.dat bs=1M count=500" test on a Transcend Class 10 at 750/255/+3:

Code: Select all

pi@raspberrypi ~ $ tail -f /var/log/syslog
Oct 12 13:48:12 raspberrypi dbus[1915]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Oct 12 13:49:13 raspberrypi kernel: [   76.890240] mmc0: final write to SD card still running
Oct 12 13:49:23 raspberrypi kernel: [   86.913336] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct 12 13:49:23 raspberrypi kernel: [   86.914533] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct 12 13:49:38 raspberrypi kernel: [  101.040923] mmc0: final write to SD card still running
Oct 12 13:49:48 raspberrypi kernel: [  111.053337] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct 12 13:49:48 raspberrypi kernel: [  111.054520] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct 12 13:50:12 raspberrypi kernel: [  135.033361] mmc0: Timeout waiting for hardware interrupt - cmd25.
Oct 12 13:50:12 raspberrypi kernel: [  135.033404] mmc0: resetting ongoing cmd 25DMA before 241664/241664 [1]/[9] complete
Oct 12 13:50:12 raspberrypi kernel: [  135.037832] mmcblk0: error -110 transferring data, sector 6192480, nr 1024, cmd response 0x900, card status 0xc00
Oct 12 13:50:12 raspberrypi kernel: [  135.038008] mmc0: DMA IRQ 6 ignored - results were reset
Oct 12 13:50:12 raspberrypi kernel: [  135.038114] end_request: I/O error, dev mmcblk0, sector 6192643
Oct 12 13:50:12 raspberrypi kernel: [  135.038145] end_request: I/O error, dev mmcblk0, sector 6192648
Oct 12 13:50:12 raspberrypi kernel: [  135.038171] end_request: I/O error, dev mmcblk0, sector 6192656
Oct 12 13:50:12 raspberrypi kernel: [  135.038195] end_request: I/O error, dev mmcblk0, sector 6192664
Oct 12 13:50:12 raspberrypi kernel: [  135.038218] end_request: I/O error, dev mmcblk0, sector 6192672
Oct 12 13:50:12 raspberrypi kernel: [  135.038241] end_request: I/O error, dev mmcblk0, sector 6192680
Oct 12 13:50:12 raspberrypi kernel: [  135.038264] end_request: I/O error, dev mmcblk0, sector 6192688
Oct 12 13:50:12 raspberrypi kernel: [  135.038288] end_request: I/O error, dev mmcblk0, sector 6192696
...
Oct 12 13:50:12 raspberrypi kernel: [  135.040128] Buffer I/O error on device mmcblk0p2, logical block 758700
Oct 12 13:50:12 raspberrypi kernel: [  135.040175] Buffer I/O error on device mmcblk0p2, logical block 758701
Oct 12 13:50:12 raspberrypi kernel: [  135.040197] Buffer I/O error on device mmcblk0p2, logical block 758702
Oct 12 13:50:12 raspberrypi kernel: [  135.040218] Buffer I/O error on device mmcblk0p2, logical block 758703
Oct 12 13:50:12 raspberrypi kernel: [  135.040237] Buffer I/O error on device mmcblk0p2, logical block 758704
Oct 12 13:50:12 raspberrypi kernel: [  135.040255] Buffer I/O error on device mmcblk0p2, logical block 758705
Oct 12 13:50:12 raspberrypi kernel: [  135.040272] Buffer I/O error on device mmcblk0p2, logical block 758706
Oct 12 13:50:12 raspberrypi kernel: [  135.040291] Buffer I/O error on device mmcblk0p2, logical block 758707
...
Oct 12 13:50:12 raspberrypi kernel: [  135.042509] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:251: I/O error writing to inode 4876 (offset 263897088 size 524288 starting block 774188)
Oct 12 13:50:16 raspberrypi kernel: [  139.168879] JBD2: Detected IO errors while flushing file data on mmcblk0p2-8
Oct 12 13:50:17 raspberrypi kernel: [  140.716760] mmc0: final write to SD card still running
Oct 12 13:50:27 raspberrypi kernel: [  150.733336] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct 12 13:50:27 raspberrypi kernel: [  150.734596] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct 12 13:50:32 raspberrypi kernel: [  155.630136] JBD2: Detected IO errors while flushing file data on mmcblk0p2-8

and let me know if the corruption has gone, and whether

Code: Select all

sudo hdparm -t /dev/mmcblk0

gives the expected result.

hdparm results WITH config/cmdline tweaks (at 750/250/+0):

Code: Select all

pi@raspberrypi ~ $ sudo hdparm -t /dev/mmcblk0

/dev/mmcblk0:
 Timing buffered disk reads:  52 MB in  3.11 seconds =  16.70 MB/sec

And just for comparison, WITHOUT the config/cmdline tweaks (at 750/250/+0):

Code: Select all

pi@raspberrypi ~ $ sudo hdparm -t /dev/mmcblk0

/dev/mmcblk0:
 Timing buffered disk reads:  52 MB in  3.12 seconds =  16.68 MB/sec

Not sure what the "expected result" should be - should the SD card performance be the same as before, or noticeably different? Wondering if the tweaks had any effect on my setup...

[dom]

Not sure what the "expected result" should be - should the SD card performance be the same as before, or noticeably different? Wondering if the tweaks had any effect on my setup...

Thanks for testing, but I do believe your problem is different from the usual core_freq>=300 => corruption.
I would expect hdparm to give the same results when you add both config.txt and cmdline.txt. If you just add one, then hdparm results will likely go down (and you may see other errors).

Can you confirm with stock (core_freq=250, over_voltage=0, arm_freq=700, sdram_freq=400) that the addition of the two emmc settings makes your system no worse than before?
I'm thinking of making this the default, if Tompen or portets see any benefit, so any confirmation that it doesn't make things worse is useful.

[milhouse]

Can you confirm with stock (core_freq=250, over_voltage=0, arm_freq=700, sdram_freq=400) that the addition of the two emmc settings makes your system no worse than before?

I can confirm that the addition of these emmc settings does NOT make a stock system any worse than before (based on brief testing, a handful of dd runs - no corruption or worrisome log entries observed).

[dom]

I can confirm that the addition of these emmc settings does NOT make a stock system any worse than before (based on brief testing, a handful of dd runs - no corruption or worrisome log entries observed).

Thanks.

[gaston]

@Tompen @portets (and others)

Can you please try (in config.txt)

Code: Select all

init_emmc_clock=100000000

and in cmdline.txt

Code: Select all

sdhci-bcm2708.emmc_clock_freq=100000000

and let me know if the corruption has gone, and whether

Code: Select all

sudo hdparm -t /dev/mmcblk0

gives the expected result.

This should work with existing kernels.

I'm trying with Turbo Mode with your settings and there is no corruption (yet).

hdparm -t /dev/mmcblk0 19.82 MB/s.

dd if=/dev/zero of=./test.dat bs=1M count=500: no errors.

[dom]

I'm trying with Turbo Mode with your settings and there is no corruption (yet).

Do you get corruption without my settings?

[gaston]

I'm trying with Turbo Mode with your settings and there is no corruption (yet).

Do you get corruption without my settings?

I get corruption almost immediately without your settings with the Turbo mode.

[dom]

I get corruption almost immediately without your settings with the Turbo mode.

That sounds promising then. Fingers crossed this fix works.

[welshblob]

Hi, been following this thread loosely but have got a bit lost with the current recommended overclock settings. What are the current recommended overclock settings and what firmware should I be using?

[simplesi]

What are the current recommended overclock settings and what firmware should I be using?

Theres no recommended - every RPi setup seems to be different and what you can achieve seems to depend on your RPi/your software versions/your SD Card/your PSU and whatever else you've got plugged in and whatever your actually doing with it.

I'd recommend (if your RPI is stable and your not messing around with it all the time) say, trying the simple Turbo mode and leave it alone for a week and see how you get on.

But if you mess around with your RPi (and who wouldn't ) then you've got to apply some testing principles and not blame the over clocking for any issues

I "Seemed" to have had corrupt SD card issues when running in Turbo mode - so I've stepped back to plain 700Mhz for a couple of weeks and I haven't had them.

So going to try plain 800Mhz next and see what happens

Although, we'd all like our Rpi to run at 2Ghz, I think we need to be realistic - the OSes/firmware/hardware isn't stable yet so its all a bit experimental - some are winning - some are not

regards

Simon

[mcmanuf]

@Tompen @portets (and others)

Can you please try (in config.txt)

Code: Select all

init_emmc_clock=100000000

and in cmdline.txt

Code: Select all

sdhci-bcm2708.emmc_clock_freq=100000000

and let me know if the corruption has gone, and whether

Code: Select all

sudo hdparm -t /dev/mmcblk0

gives the expected result.
This should work with existing kernels.

dom, if not turbo mode, but fx 950Mhz (or 900Mhz or something else!).

Should the two lines above then be

Code: Select all

init_emmc_clock=95000000

and

Code: Select all

sdhci-bcm2708.emmc_clock_freq=95000000

[dom]

Dom, if not turbo mode, but fx 950Mhz (or 900Mhz or something else!).
Should the two lines above then be

Code: Select all

init_emmc_clock=95000000

and

Code: Select all

sdhci-bcm2708.emmc_clock_freq=95000000

No. emmc clock should be fixed at 100MHz. Doesn't matter what the arm or core frequency is.

[mcmanuf]

---- deleted

[ZirconiumX]

Though I know this shouldn't be in the overclocking forum - setting the *_freq_min settings makes my HDMI blank out. It works fine without them.

Matthew:out

[dom]

Though I know this shouldn't be in the overclocking forum - setting the *_freq_min settings makes my HDMI blank out. It works fine without them.

Yes, core_freq_min or sdram_freq_min would cause this. I'd guess you need 100-200MHz for each of those to maintain a 1080p display.
Lower resolution, framerate or bit depth would allow you to get lower.

[portets]

Will try to do some testing today. Trying to get over a wisdom tooth issue right now.

Anyone see this? http://www.raspberrypi.org/phpBB3/viewt ... 33#p193333
They said a capacitor across a couple of sd pins fixed corruption.