Overclocking

[dms75]

It seems i have a very overcurrent sensitive pi.
I managed to get it stable (Quake3 stable) with
950 arm
core 250
sdram 400
overvolt 2

With anything more overvolt or frequencies i get resets under Quake3.

Without any overvolting i can still reach
arm 900
core 333
sdram 500

which is probably better for for the arm computing side all in all.

Is it still possible to use force_turbo without overvolting and not loosing the warranty?
If yes I might have a go at higher gpu frequencies without overvolting and check how far i can go there.

Dirk

[RasmusHC]

Hi all

I like the new dynamic overclocking option. But I have one question, I have set the arm_freq=900 and when I run the “dmesg |grep cpufreq” command I can see it change so everything works.

But I can also see that is change the governor type and it ends up with the “conservative” option.

Can one of you please explain why that happen, I thought it would keep using the “ondemand” option?

BTW: I’m running OpenELEC r11949 image from the 17th of September.

Here is the output from “dmesg |grep cpufreq”

Code: Select all

root ~ # dmesg |grep cpufreq
[    1.307483] bcm2835-cpufreq: min=700000 max=900000 cur=700000
[    1.307597] bcm2835-cpufreq: switching to governor ondemand
[    1.307615] bcm2835-cpufreq: switching to governor ondemand
[    2.020184] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
[    2.390200] bcm2835-cpufreq: Freq 900000->700000 (min=700000 max=900000 target=700000 request=700000)
[    3.589497] bcm2835-cpufreq: switching to governor performance
[    3.589526] bcm2835-cpufreq: switching to governor performance
[    3.590280] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
[   22.447464] bcm2835-cpufreq: switching to governor conservative
[   22.447491] bcm2835-cpufreq: switching to governor conservative

[dom]

It seems i have a very overcurrent sensitive pi.
I managed to get it stable (Quake3 stable) with
950 arm
core 250
sdram 400
overvolt 2

With anything more overvolt or frequencies i get resets under Quake3.

Without any overvolting i can still reach
arm 900
core 333
sdram 500

which is probably better for for the arm computing side all in all.

Is it still possible to use force_turbo without overvolting and not loosing the warranty?
If yes I might have a go at higher gpu frequencies without overvolting and check how far i can go there.

Dirk

Most likely it is your power supply that is borderline, and the increased power required when overclocked is causing a voltage drop, and so a reset.
Measuring the voltage just before it resets may be interesting.

force_turbo=1 will only set the warranty bit if over_voltage is also set.

[dms75]

I rather don't think it's the power supply, because for those tests i had my rpi connected to an Agilent Lab-powersupply capable of 20A at 5V (current limit set to 1500mA) and I'm powering via the GPIO header, so there is no polyfuse in the supplychain either.
The current consumption (Pi + keyboard +mouse) is around 600-700mA as displayed by the powersupply when the reset occurs but that display is probably too slow to actually show a very fast drop in the 5V rail if it were to occur. On monday I could insert a measurement shunt in the supply and hook up an Oscilloscope to get the exact currents and voltages of the 5V rail I suppose, but I rather doubt that there will be any relevant drop to measure. If I'm at it i might as well check the other Voltages on board as well just to make sure I'm not having some sort of brown out...
Are there any convinient testpoints for the core voltages?

Dirk

[dom]

I rather don't think it's the power supply, because for those tests i had my rpi connected to an Agilent Lab-powersupply capable of 20A at 5V (current limit set to 1500mA) and I'm powering via the GPIO header, so there is no polyfuse in the supplychain either.
The current consumption (Pi + keyboard +mouse) is around 600-700mA as displayed by the powersupply when the reset occurs but that display is probably too slow to actually show a very fast drop in the 5V rail if it were to occur. On monday I could insert a measurement shunt in the supply and hook up an Oscilloscope to get the exact currents and voltages of the 5V rail I suppose, but I rather doubt that there will be any relevant drop to measure. If I'm at it i might as well check the other Voltages on board as well just to make sure I'm not having some sort of brown out...
Are there any convinient testpoints for the core voltages?

If it's not the power supply, then it's the SMPS on the SoC. It will reset the chip when the current reaches a threshold. It can be disabled (with current_limit_override), but that is considered experimental and does set the warranty bit.

[ajstarks]

Has anybody seen the case where Turbo mode renders sshd unusable? (it hangs)

[portets]

My pi also seems particularly sensitive to overcurrent. I'm using a high quality regulated 5v bypassing the polyfuse as well. Tested overclocks using quake3 and compiling various programs.

no overvolt:
arm_freq=990
sdram_freq=600
core_freq=450

with over_volt=6:
arm_freq=950
sdram_freq=500
core_freq=400

with over_volt=6 and current limit disabled:
arm_freq=1150
sdram_freq=600
core_freq=550

I've also noticed that core_freq above 450 and arm_freq above 1000 will completely destroy my filesystem on boot with force_turbo=1. But these settings(and higher) with force turbo off can compile or play quake3 for hours no problem. Is the boot process just that sensitive?

[jumon]

don't look at /proc/cpuinfo as that will only tell you the boot value

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

is what you want

I dont have anything below the cpu0 directory there. Am I missing some packages that add that?

[dom]

I've also noticed that core_freq above 450 and arm_freq above 1000 will completely destroy my filesystem on boot with force_turbo=1. But these settings(and higher) with force turbo off can compile or play quake3 for hours no problem. Is the boot process just that sensitive?

I'm afraid I just don't know yet. My view was that an unstable overclock might corrupt the filesystem as it crashed. But it seems there is another effect that I don't see.
I need more bug reports before I can guess.

I'd be interested in people experimenting with each of the values in the overclock (arm_freq, core_freq, sdram_freq and over_voltage).
Try reducing each of those back to stock and report which of them is critical to the corruption occurring.

Also if you can try on more than one sdcard - possibly some sdcards are more succeptible.

[dom]

I dont have anything below the cpu0 directory there. Am I missing some packages that add that?

Yes, you are lacking the cpufreq driver.
Did you start with the latest raspbian/wheezy image from the download page?
If it was the previous raspbian/wheezy image, then "sudo apt-get update && sudo apt-get upgrade" should get you it.
If you started from a different image, then it's more complicated...

[thogue]

I had a corrupt / partition.

I wasn't able to do a full repair it only got worse with repair. ( from single user mode ro originally then I set fstab to check on boot.

Was running turbo and I might of turned off the power source without halting the system. Honestly it was early and I was not fully awake

Edit. 16GB SanDisk Class4

[portets]

I'd be interested in people experimenting with each of the values in the overclock (arm_freq, core_freq, sdram_freq and over_voltage).
Try reducing each of those back to stock and report which of them is critical to the corruption occurring.

Also if you can try on more than one sdcard - possibly some sdcards are more succeptible.

Tried 2 sd cards. pny 4gb class 4(10.5MB/s read, 6.1MB/s write), sandisk microsd 4gb class 2(20.2MB/s read, 16MB/s write). Both lost the ext4 filesystem completely. Will do more testing, but it strongly seems like core_freq is what's doing them in.

[hojnikb]

I've also have had sd card corrupted like this, when i overclocked my core_freq.
Guess this freq is kinda sensitive to other chips aswell, so ill keep that stock for now

[milhouse]

With the latest OpenELEC nightly (r11978) I can consistently corrupt the ext4 filesystem with just a minor core overclock of arm_freq=750, core_freq=300, over_voltage=+3 (the last setting just for good measure). sdram_freq is stock at 400.

I was forced to overclock the ARM to 750 since the Core clock would be stuck at 250 unless the ARM is being overclocked - not sure if this is normal/expected behaviour or a feature of the current OpenELEC firmware which dates from 16 Sep (could the age of this firmware also be a reason for the SD corruption?):

Code: Select all

root ~ # vcgencmd version
Sep 16 2012 14:37:58
Copyright (c) 2012 Broadcom
version 337302 (release)

Maybe I could cause the SD corruption with a Core overclock alone (ie. ARM at 700), but unfortunately the current OpenELEC firmware doesn't seem to allow this.

Here's an example of a freshly imaged Transcend 8GB Class 10 card booting OpenELEC r11978 with ARM=750 and Core=300. There is no input at the menu, just wait and the SD card begins to corrupt itself:

Code: Select all

Sep 22 01:02:07 openelec user.notice Boot: ### set cpu's to 'ondemand' ###
Sep 22 01:02:07 openelec user.info kernel: [   23.906155] bcm2835-cpufreq: switching to governor ondemand
Sep 22 01:02:10 openelec user.info kernel: [   23.906181] bcm2835-cpufreq: switching to governor ondemand
Sep 22 01:02:10 openelec user.err kernel: [   26.411422] mmc0: final write to SD card still running
Sep 22 01:02:20 openelec user.err kernel: [   36.428073] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 01:02:20 openelec user.err kernel: [   36.429244] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 01:02:20 openelec user.notice Boot: ### SSH: generating SSH2 RSA key ###
Sep 22 01:02:28 openelec user.err kernel: [   45.252964] mmc0: final write to SD card still running
Sep 22 01:02:38 openelec user.info kernel: [   46.508970] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 01:02:38 openelec user.err kernel: [   55.268045] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 01:02:38 openelec user.err kernel: [   55.269322] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 01:02:39 openelec user.notice Boot: ### SSH: generating SSH2 DSA key ###
Sep 22 01:02:40 openelec user.info kernel: [   55.988848] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 01:02:40 openelec user.err kernel: [   56.523640] mmc0: final write to SD card still running
Sep 22 01:02:43 openelec user.notice Boot: ### Starting SSH Server ###
Sep 22 01:02:50 openelec user.info kernel: [   59.798940] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 01:02:50 openelec user.err kernel: [   66.528040] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 01:02:50 openelec user.err kernel: [   66.529206] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 01:02:50 openelec user.info kernel: [   66.878861] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 01:02:55 openelec user.info kernel: [   67.238976] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 01:02:57 openelec user.info kernel: [   72.019013] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 01:02:57 openelec user.info kernel: [   73.519046] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 01:02:58 openelec user.info kernel: [   73.878852] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 01:02:58 openelec user.info kernel: [   74.599147] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 01:02:59 openelec user.info kernel: [   74.958884] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 01:03:01 openelec user.info kernel: [   75.338985] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 01:03:17 openelec user.info kernel: [   77.612688] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 01:03:17 openelec user.err kernel: [   93.400534] mmc0: final write to SD card still running
Sep 22 01:03:27 openelec user.err kernel: [  103.408105] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 01:03:27 openelec user.err kernel: [  103.409327] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 01:03:30 openelec user.err kernel: [  107.050247] mmc0: final write to SD card still running
Sep 22 01:03:40 openelec user.err kernel: [  117.068076] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 01:03:40 openelec user.err kernel: [  117.069241] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 01:03:40 openelec user.err kernel: [  117.245882] mmc0: final write to SD card still running
Sep 22 01:03:50 openelec user.err kernel: [  127.248082] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 01:03:50 openelec user.err kernel: [  127.249258] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

Rebooting this system after the SD card errors appeared in the log failed with the error "mount: mounting /dev/mmcblk0p2 on /stroage failed: Invalid argument".

Unfortunately my SD card drawer is only full of Transcend SD cards, though I am on my second Transcend 8GB Class 10 as when I first came across this corruption I blamed the card going bad, and cracked open a second which has behaved identically.

[jumon]

I dont have anything below the cpu0 directory there. Am I missing some packages that add that?

Yes, you are lacking the cpufreq driver.
Did you start with the latest raspbian/wheezy image from the download page?
If it was the previous raspbian/wheezy image, then "sudo apt-get update && sudo apt-get upgrade" should get you it.
If you started from a different image, then it's more complicated...

That was exactly it. I had installed from BerryBoot.
After your post I installed from the image on the download page and all is good now. Thanks!!!!!!

[Frank B]

I'd be interested in people experimenting with each of the values in the overclock (arm_freq, core_freq, sdram_freq and over_voltage).
Try reducing each of those back to stock and report which of them is critical to the corruption occurring.

Also if you can try on more than one sdcard - possibly some sdcards are more succeptible.

Tried 2 sd cards. pny 4gb class 4(10.5MB/s read, 6.1MB/s write), sandisk microsd 4gb class 2(20.2MB/s read, 16MB/s write). Both lost the ext4 filesystem completely. Will do more testing, but it strongly seems like core_freq is what's doing them in.

Yes, my pi shows the same behavior and for my pi, i'm pretty sure that core_freq is the problem.
i can't go higher than 320..350 (didnt find out exactly). overvolt=6. Tested with various Sandisk (Extreme III, Ultra II, simple class 4) & Samsung class 6 cards.

Each time, filesystem was corrupted. A good test is to do apt-get update after re-imaging and look what dmesg says. if there are sdcard errors, the filesystem gets corrupted in a short while...
Power Supply is 5 A.

Frank.

[dom]

Yes, my pi shows the same behavior and for my pi, i'm pretty sure that core_freq is the problem.
i can't go higher than 320..350 (didnt find out exactly). overvolt=6. Tested with various Sandisk (Extreme III, Ultra II, simple class 4) & Samsung class 6 cards.

Thanks Frank and Milhouse. It seems there are two possibilities for higher core frequency causing corruption:
Two consecutive accesses to the sdcard peripheral can occur closer together and that is not liked by the sdcard or the sdcard peripheral.
The limiting timing path is from the arm to the sdcard peripheral and this is the first thing that fails when the core frequency is too high resulting in the sdcard peripheral seeing garbage.

The first problem could possibly be solved by inserting delays in the right place in the sdcard driver. This would be more likely if some sdcards were were unaffected.
The second is likely a hard limitation of the specific chip. Some chips may be more susceptible. It will likely affect all sdcards equally. The only solution in keeping below your specific safe frequency.

It feels like the second case is more probable. Anyone with corruption issues who wants to help with this problem, I'd like to know:
Are all sdcards affected equally.
What is the maximum core_freq that avoids corruption.

[milhouse]

Thanks Frank and Milhouse. It seems there are two possibilities for higher core frequency causing corruption:
Two consecutive accesses to the sdcard peripheral can occur closer together and that is not liked by the sdcard or the sdcard peripheral.
The limiting timing path is from the arm to the sdcard peripheral and this is the first thing that fails when the core frequency is too high resulting in the sdcard peripheral seeing garbage.

The first problem could possibly be solved by inserting delays in the right place in the sdcard driver. This would be more likely if some sdcards were were unaffected.
The second is likely a hard limitation of the specific chip. Some chips may be more susceptible. It will likely affect all sdcards equally. The only solution in keeping below your specific safe frequency.

It feels like the second case is more probable. Anyone with corruption issues who wants to help with this problem, I'd like to know:
Are all sdcards affected equally.
What is the maximum core_freq that avoids corruption.

What's really strange is that I have been able to compile Quake3 (a task that took 40 minutes) on Raspbian with settings of 1000/500/450/+3, and no corruption - obviously with lots of writes to the SD card going on at this time. It's only OpenELEC that has exhibited these problems - admittedly, the GPU is getting more of a workout than the command line Raspbian, but also the firmware is older in OE. I'll see if I can snaffle some different SD cards, might have a Transcend Class 2 I can use.

[Lob0426]

I have been running all three of my RasPii at core_freq=320 and have not been having SD corruption. At least since Raspbian 8/16. I just set my RasPi server up with raspi-config to go up to 333, but it will vary rarely go into turbo mode anyway. All of my RasPii failed in Quake3 at 350 core with no over volt. #1 has Hynix memory and the other two have Samsung.

Last night I set the Lapdock up to go to 950, which I had tested it too with no over volt. I think the core is 400 or 450. The trouble is it uses a HDD. So I do not know if it will show the corruption issue or not. I do know that I had a RasPi that I RMAed that would not work with rootfs on the SD but it ran fine when running from a HDD. It corrupted the boot of the SD whenever I tried to rpi-update it. So not the issue at hand here. It is using a Transend 8GB class 4.

I wonder if people with root on USB drives are having any corruption problems. My Lapdock has been rock solid. My server ate a SD card on Friday. But it was unplugged without a halt or shutdown sent.

[milhouse]

I'll see if I can snaffle some different SD cards, might have a Transcend Class 2 I can use.

OK, same problems with the Transcend 8GB Class 2 card (750/300 overclock settings for ARM and Core): A fresh image of OE r11978, boot it, wait in the GUI for a few minutes (don't do anything, no input), then reboot the system and the second partition will have been trashed.

I've just configured OE to mount root from a USB memory stick (a Verbatim 8GB) and obviously no more SD errors, it's stable and perfectly usable so maybe this will be a short (even long) term solution if overclocked systems are more choosy about their SD cards.

I'll continue to try and identify the absolute minimum ARM/Core settings required for SD corruption.

[shalo]

What SD cards are you guys using, if using them at all? I tried 3 sd cards with different overclock stability results on raspbian wheezy official 2012-7-15 no updates, upgrades performed. I don't know if drives are factor on overclocks but these are some rough tinkering with observations.

All of them 16GB's. Just booting up and entering lxde. No overvoltage. No change on gpu_freq, sdram_freq
1. pny class 4 premium started to go funny and stopped working around
arm_freq=850-860

2. sandisk class 4 ultra started to go funny and stopped working around
arm_freq=890-900

3. sandisk class 10 ultra started to go funny and stopped working around
arm_freq=930-940

From these disks sandisk class 4 ultra had pretty neat mouse response improvements on
arm_freq=882
gpu_freq=294
sdram_freq=400
This thing actually got pretty usable without much mouse stuttering and midori got better on this setting. Hope someone's current rpi experience improve without overvolting. Cheers

I don't understand this but I saw broadly the same thing, especially when I added some over-voltage. With a 4gb Sandisk class 4 card I saw some corruption twice on the ext4 partition around ~925mhz+. When I moved the OS to a usb disk it was fine up to 1100mhz with 1150 causing a crash but no corruption.

There seems to be something in the SD card used. I thought when testing I would just use sd card for simplicity's sake but saw very quick corruption to SD card data above 900mhz. When using a USB flash drive for the operating system, I benched 1100mhz with 6 overvolt. 1150 was too much but didn't corrupt any data.

These are from a way back in this thread so I guess some people missed it. That one guy seems to have been more thorough in his testing and both of us appear to have noticed it with just the ARM, though I don't recall core_freq. My sandisk class 4 result matched his though...

[thogue]

crashed pulling too much power from the USB (plugged in keyboard, caused a crash), was powering via 2407WFP Dell monitor.

lost root filesystem again, this time I hooked it up to an ubuntu box and after I finished repairing it looks like about 1/4 of everything is now inside lost+found :-/ Looks like another reinstall is about to happen. I got it working again but the amount if time it will take me to move the files back I might as well just reinstall.


Going to turn down turbo and see if it stabilizes. Newer sd cards next week I can do more testing.

[john202]

I have issues with corrupted filesystem after overclocking, too.

I did some testing.
Everything works fine @ ARM_freq=900, without overvoltage, sdram: 450Mhz.

But, then I overclocked avr_freq to 1100MHz, Overvoltage: 6, SDRam 500MHz, core_freq not changed.
It runs fine (infinite loop, 100% arm usage for about 30 minutes without any issues) until I write something on the card.

For example after running apt-get update I got errors in kern.log:

Code: Select all

Sep 22 18:54:31 raspberrypi kernel: [   36.419483] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Sep 22 18:54:31 raspberrypi kernel: [   39.272893] bcm2835-cpufreq: switching to governor ondemand
Sep 22 18:54:32 raspberrypi kernel: [   39.272930] bcm2835-cpufreq: switching to governor ondemand
Sep 22 18:54:32 raspberrypi kernel: [   42.213692] mmc0: final write to SD card still running
Sep 22 18:54:42 raspberrypi kernel: [   52.159663] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 18:54:42 raspberrypi kernel: [   52.160905] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 19:00:59 raspberrypi kernel: [  395.286972] mmc0: final write to SD card still running
Sep 22 19:01:09 raspberrypi kernel: [  405.302615] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 19:01:09 raspberrypi kernel: [  405.302823] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 19:01:14 raspberrypi kernel: [  410.954322] mmc0: final write to SD card still running
Sep 22 19:01:24 raspberrypi kernel: [  420.962785] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 19:01:24 raspberrypi kernel: [  420.965447] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 19:01:31 raspberrypi kernel: [  427.305574] mmc0: final write to SD card still running
Sep 22 19:01:41 raspberrypi kernel: [  437.322899] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 19:01:41 raspberrypi kernel: [  437.324118] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 19:02:54 raspberrypi kernel: [  511.043518] mmc0: Timeout waiting for hardware interrupt - cmd25.
Sep 22 19:02:54 raspberrypi kernel: [  511.043573] mmc0: resetting ongoing cmd 25DMA before 57344/57344 [57]/[77] complete
Sep 22 19:02:54 raspberrypi kernel: [  511.045670] mmcblk0: error -110 transferring data, sector 2692008, nr 1024, cmd response 0x900, card status 0xc00
Sep 22 19:02:54 raspberrypi kernel: [  511.046885] mmc0: DMA IRQ 6 ignored - results were reset
Sep 22 19:02:54 raspberrypi kernel: [  511.047028] end_request: I/O error, dev mmcblk0, sector 2692601
Sep 22 19:02:54 raspberrypi kernel: [  511.047067] end_request: I/O error, dev mmcblk0, sector 2692608
Sep 22 19:02:54 raspberrypi kernel: [  511.047100] end_request: I/O error, dev mmcblk0, sector 2692616
Sep 22 19:02:54 raspberrypi kernel: [  511.047133] end_request: I/O error, dev mmcblk0, sector 2692624

(...)

Sep 22 19:02:54 raspberrypi kernel: [  511.048391] end_request: I/O error, dev mmcblk0, sector 2692984
Sep 22 19:02:54 raspberrypi kernel: [  511.048464] end_request: I/O error, dev mmcblk0, sector 2693008
Sep 22 19:02:54 raspberrypi kernel: [  511.048487] end_request: I/O error, dev mmcblk0, sector 2693016
Sep 22 19:02:54 raspberrypi kernel: [  511.048511] end_request: I/O error, dev mmcblk0, sector 2693024
Sep 22 19:02:54 raspberrypi kernel: [  511.048548] Buffer I/O error on device mmcblk0p2, logical block 321141
Sep 22 19:02:54 raspberrypi kernel: [  511.048589] Buffer I/O error on device mmcblk0p2, logical block 321142
Sep 22 19:02:54 raspberrypi kernel: [  511.048619] Buffer I/O error on device mmcblk0p2, logical block 321143

After that raspian is unusable:

Code: Select all

pi@raspberrypi ~ $ ls
-bash: /bin/ls: cannot execute binary file
-bash: relocation error: -bash: symbol me, version GLIBC_2.4 not defined in file libc.so.6 with link time reference
pi@raspberrypi ~ $ whoami
-bash: whoami: command not found
-bash: relocation error: -bash: symbol me, version GLIBC_2.4 not defined in file libc.so.6 with link time reference
pi@raspberrypi ~ $ sudo halt
sudo: halt: command not found

I have SanDisk 8GB Class 10 (Up to 30MB/s).
I will have another sd card next week (Verbatim 8GB Class 4), and I will do some more tests.
I'm using phone charger 5V@1A, and active USB Hub, so there should be enough power.
I hope this will help somehow.

[milhouse]

I've now observed corruption of a Transcend Class 2 SD card running OpenELEC r11978 with the following overclock settings:

Code: Select all

arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3

I created a fresh image of r11978 with settings of 750/250/400/+3 and booted the system, then rebooted it 4 times (all boots were successful).

I then increased core_freq from 250 to 255, booted with the new settings, observed SD card errors, rebooted, and it failed due to ext4 corruption.

The boot log (of the first boot at 255) is shown below - the SD card errors start after 45 seconds:

Code: Select all

...
Jan  1 00:00:10 openelec daemon.info avahi-daemon[893]: Registering new address record for 192.168.0.17 on eth0.IPv4.
Jan  1 00:00:10 openelec daemon.err connmand[877]: Deleting host route failed (No such process)
Jan  1 00:00:11 openelec daemon.info connmand[877]: eth0 {add} address 192.168.0.17/24 label eth0 family 2
Jan  1 00:00:11 openelec daemon.info connmand[877]: ntp: time slew +1348343300.416767 s
Sep 22 19:48:31 openelec daemon.info connmand[877]: eth0 {add} route 192.168.0.0 gw 0.0.0.0 scope 253 <LINK>
Sep 22 19:48:31 openelec daemon.info connmand[877]: eth0 {add} route 192.168.0.1 gw 0.0.0.0 scope 253 <LINK>
Sep 22 19:48:31 openelec daemon.info connmand[877]: eth0 {add} route 0.0.0.0 gw 192.168.0.1 scope 0 <UNIVERSE>
Sep 22 19:48:31 openelec daemon.err connmand[877]: Setting default gateway route failed (File exists)
Sep 22 19:48:31 openelec daemon.info connmand[877]: eth0 {add} route 81.169.141.235 gw 192.168.0.1 scope 0 <UNIVERSE>
Sep 22 19:48:31 openelec daemon.info connmand[877]: Client-IP: 188.222.193.237
Sep 22 19:48:31 openelec daemon.info connmand[877]: Client-Country: GB
Sep 22 19:48:31 openelec daemon.info connmand[877]: eth0 {del} route 81.169.141.235 gw 192.168.0.1 scope 0 <UNIVERSE>
Sep 22 19:48:34 openelec user.info kernel: [   14.029268] input: eventlircd as /devices/virtual/input/input2
Sep 22 19:48:36 openelec user.notice Boot: ### Starting Samba server ###
Sep 22 19:48:38 openelec user.notice Boot: ### SSH: generating SSH2 RSA key ###
Sep 22 19:48:39 openelec daemon.err smbd[1090]: [2012/09/22 19:48:39.523489,  0] passdb/pdb_smbpasswd.c:248(startsmbfilepwent)
Sep 22 19:48:39 openelec daemon.err smbd[1090]:   startsmbfilepwent_internal: file /var/run/smbpasswd did not exist. File successfully created.
Sep 22 19:48:42 openelec user.notice Boot: ### set cpu's to 'ondemand' ###
Sep 22 19:48:42 openelec user.info kernel: [   22.359597] bcm2835-cpufreq: switching to governor ondemand
Sep 22 19:49:06 openelec user.info kernel: [   22.359624] bcm2835-cpufreq: switching to governor ondemand
Sep 22 19:49:06 openelec user.err kernel: [   45.967145] mmc0: final write to SD card still running
Sep 22 19:49:16 openelec user.info kernel: [   47.298760] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 19:49:16 openelec user.err kernel: [   55.967929] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 19:49:16 openelec user.err kernel: [   55.969152] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 19:49:17 openelec user.notice Boot: ### SSH: generating SSH2 DSA key ###
Sep 22 19:49:17 openelec user.info kernel: [   57.148859] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 19:49:17 openelec user.err kernel: [   57.336869] mmc0: final write to SD card still running
Sep 22 19:49:27 openelec user.info kernel: [   60.508760] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 19:49:27 openelec user.err kernel: [   67.347928] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 19:49:27 openelec user.err kernel: [   67.349142] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 22 19:49:27 openelec user.notice Boot: ### Starting SSH Server ###
Sep 22 19:49:38 openelec user.info kernel: [   76.778978] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 19:49:39 openelec user.info kernel: [   78.578961] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 19:49:40 openelec user.info kernel: [   79.298952] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 19:49:41 openelec user.info kernel: [   79.658878] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 22 19:50:01 openelec user.info kernel: [   80.739060] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 22 19:50:01 openelec user.err kernel: [  100.605428] mmc0: final write to SD card still running
Sep 22 19:50:11 openelec user.err kernel: [  110.607998] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 22 19:50:11 openelec user.err kernel: [  110.609261] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

Hard to believe my hardware (core) is this marginal - hopefully it's just the Transcend cards that don't play nice with even a slightly overclocked core. Shame, as in every other respect they're decent, well priced cards... and I've got a ton of them!

[thogue]

Found a 1gb SD card(Sandisk unlabeled) and loaded the "minimal install". Seems to not have an issue with corruption on turbo. Done it twice with the 16g card again. once on 1000 and once again on the 950 setting. Trying 900 setting now with the 16g sandisk.

provoked a crash via overpower while factoring primes 2 times and no corruption while running on medium. I will stick to this setting for this card for now.