Overclocking the PI does not work on Raspbian OS? (solved)

[Patschi]

Hi, I tried today to overclock my Raspberry Pi, but it still won't work. I always edit the /boot/config.txt and added following lines:

arm_freq=875
sdram_freq=500

But always when I reboot my Pi, the settings will be removed from the file... And at the end there is always some characters like "@~@@@-@@..."

I have the latest Debian wheezy version (Raspbian). Someone has a idea?
Thanks for any help!

Greets from Austria,
Patschi

[asb]

Ok, there have been sporadic reports of this happening for a while now and we're really trying to get to the bottom of it. It seems really bizarre that corruption only ever seems to be reported on the FAT partition. So, do chime in with anything at all you think might be relevant. To get things started:

* What SD card do you have?
* Can you reliably reproduce this from a freshly written image?
* Do you reboot 'properly' (e.g. sudo reboot or at the very least executing sync after editing the config.txt)?
* Is your SD card definitely seated properly?
* Do you get any error messages in dmesg?
* If you can reliably reproduce it then try 1) edit config.txt, 2) cat config.txt and check it's uncorrupted, 3) sync, 4) sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" 5) cat config.txt and see if it still appears as expected, 6) sudo reboot and see if config.txt is still happy

[dukla2000]

I had this when testing the Debian Wheezy beta. I was using a slower SDcard and the response when confirming the filename to save in nano was dire, to the extent that I wasn't sure I had hit return etc. And thus at first I thought it was my doodling. And later figured it was related to the repeating keys/keyboard issue.

The corruption was always the end of the file (config.txt), never caused any syntax error, and also seemed to self-cure somehow. I worked around by putting what I wanted at the start of the file (that was about the time the file was released with a fully commented out version with all the options.) I was playing options to improve my screen display and got into a routine to edit/save the file, cat it (to check my edits had stuck and what was on the end), reboot etc. Sometimes I felt the cat showed different (less) corruption than was in nano after the save. Often had to say to nano NOT to save (after I had done the save I wanted but crud had appeared before I could exit.

No idea what it was even with hindsight - my waters say related to the repeating key problem but could be wrong.

[Patschi]

* What SD card do you have?

Transcend Extreme-Speed SDHC 16GB Class 10: http://www.amazon.de/gp/product/B002WE4HE2/

* Can you reliably reproduce this from a freshly written image?

Yep, just changed the basic settings with the new menu.

* Do you reboot 'properly' (e.g. sudo reboot or at the very least executing sync after editing the config.txt)?

I only used "reboot" yet

* Is your SD card definitely seated properly?

"Seated"?

* Do you get any error messages in dmesg?

When starting or stopping? And how can I filter the entries? What I've to search in dmesg?

* If you can reliably reproduce it then try 1) edit config.txt, 2) cat config.txt and check it's uncorrupted, 3) sync, 4) sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" 5) cat config.txt and see if it still appears as expected, 6) sudo reboot and see if config.txt is still happy

After Step 3 the file was different than the version before... There was some thing like this instead the "arm_freq..":

# overclock
arm_fcomposit

(This was the full text, I didn't cutted it)

[asb]

By seated I mean "making proper contact" as in shoved in firmly.

To clarify, if you cat config.txt immediately after writing it, it was fine, but you saw corruption if you cat it again after a sync? So it was already showing corrupted before you did the drop_caches?

[Patschi]

Only after the drop_caches the files was corrupt. Do you have the original config for me, please?

[asb]

Only after the drop_caches the files was corrupt. Do you have the original config for me, please?

Sure, https://github.com/asb/spindle/blob/mas ... tage2#L244

Regarding dmesg, I'm particularly interested in any messages prefixed with 'mmc0:'. I would check dmesg after writing config.txt and doing a sync. Just save and upload the whole thing if unsure (dmesg > my_dmesg.out).

Thanks, this is very useful. Clearly the kernel is under the impression something was correctly written to SD when in fact it was not (as shown when we drop the cache and actually re-read the file).

[Patschi]

Saving the default settings works without any problems... Well, I've overwritten the file with the original content and rebooted the Raspberry Pi.

What I did now:

cat config.txt # All okay
nano config.txt # Edited the two lines at the end of the file
cat config.txt # Still all okay
sync # Still all okay (executed twice)
drop_caches # Still all okay
cat config.txt # Still all okay
reboot # Waiting...
cat config.txt # Still all okay

Sorry, but I think I forgot the "sync"-command before
But now the file is the same from the last reboot! It seems to work!
Thanks!!

I've a short question: How I can read the temperatures of the RaspBi? Is this possible? "lm-sensors" seems not to work. Thank you very much for your great help!!

[jojopi]

I was surprised to see (via "sudo sysctl -w vm.block_dump=1", dmesg) that nearly all reads and writes on mmcblk0p1 are in single-sector or odd-multiple strides. This is despite the fact that the filesystem has 16-sector clusters that are correctly aligned. (By contrast, all I/O on mmcblk0p2 is in exact multiples of 8 sectors as one would expect.)

I have not been able to reproduce any vfat corruption myself, but here at least is one difference that could be a factor for those that have. Especially those where the first 1024 bytes are correct and the rest are junk. Presumably the behaviour would be closer to ext4 if we could increase the logical sector size instead ("mkdosfs -S4096 -s2"). But I do not think the Pi can boot from such a filesystem.

Code: Select all

[  931.502574] nano(7213): READ block 69456 on mmcblk0p1 (3 sectors)
[  936.366660] nano(7215): dirtied inode 208 (config.txt) on mmcblk0p1
[  966.778838] flush-179:0(7191): WRITE block 12224 on mmcblk0p1 (3 sectors)
[  966.779060] flush-179:0(7191): WRITE block 80 on mmcblk0p1 (1 sectors)
[  966.779154] flush-179:0(7191): WRITE block 18 on mmcblk0p1 (1 sectors)
[  966.779231] flush-179:0(7191): WRITE block 32 on mmcblk0p1 (1 sectors)
[  966.779295] flush-179:0(7191): WRITE block 50 on mmcblk0p1 (1 sectors)
[  966.779367] flush-179:0(7191): WRITE block 64 on mmcblk0p1 (1 sectors)

[jbeale]

I've a short question: How I can read the temperatures of the RaspBi? Is this possible? "lm-sensors" seems not to work.

Unfortunately there are no sensors of any kind available* on the R-Pi, although you could add your own with GPIO pins.

*(Apparently there are some on-chip temperature sensors, but not accessible; factory use only.)

[Patschi]

Because of some problems I reinstalled my Raspberry Pi and tried to overclock it too. But now I've the same problem than before.

I also tried the commands, which worked before, but the commands aren't working anymore... Always when I drop the caches the config.txt file is corrupted.

Someone have a idea why?

[Mr.Dave]

Don't have much experience with linux and don't have my Pi yet so this might not be any help at all, and if it is becoming corrupt it probably won't help either, but what if you edit the file to your liking, save it and then set the permissions on that file to 'read only' system wide ?

[W. H. Heydt]

...3) sync...

A bit late, but here's a point to consider when using sync (an old unix trick and the reason for it).

Sync will return to a prompt before it completes. The be *certain* that sync has completed, do:

Code: Select all

sync; sync

That way, you won't get a new prompt until the first sync has completed.

A common (old) unix practice when finishing a session was:

Code: Select all

sync; sync; logout

[sovet]

I've found a rather strange but effective, at least for me, workaround for the issue.

1: open a terminal and sudo sh
2: apt-get update && apt-get dist-upgrade
3: cd /boot
4: nano /boot/config.txt
5: insert whatever overclock settings you want.
6: save the file then run sync
7: cp config.txt config.txt.save
8: cp config.txt config.txt.save.1
9: sync; sync; exit; exit
10: After 9 is done move to another tty CTRL + ALT + F2
11: login
12: sync; sync; shutdown -hP now
13: unplug and replug
14: enjoy

I know it's kind of a wonky workaround, but it seems to be working for me. I forget what it was I was doing exactly, but the terminal shouted at me that it was having issues with the config.txt.save file. After trying a few different things this craziness is what I found to work.
I have noticed if you set your values too high it will still corrupt your config.txt file. Don't ask me why I'm still taking baby steps in this whole admin thing.

[Patschi]

I try it right now and it seems to work - thank you!

[Chypsylon]

Sovet's solution didn't work for me. The last line was still commented out again after a reboot.
So I tried to leave the last line as it is and just wrote it on top of the file and that did it for me

I'm using a Kingston 4GB SDHC Class 4 (was marked in wiki with:"works but gets mmc errors: mmc0: final write to SD card still running. Russel King might have a kernel patch for this problem.")

dmesg shows some mmc0 errors editing config.txt and doing a sync: http://pastebin.com/hNxKLGHH (at the very end)

[sovet]

Sovet's solution didn't work for me. The last line was still commented out again after a reboot.
So I tried to leave the last line as it is and just wrote it on top of the file and that did it for me

I did get that issue at one point as well. My fix was to put some sacrificial text at the bottom of the .config.txt before saving it. I wrote something along the lines of "Oh great computer gods smile upon me, and allow my pi to achieve its true potential, and yay they did, and on the second boot there was light."

[lb]

Hmm, so basically single-sector writes do not work reliably with some SD cards? That's something worth looking into. It shouldn't require workarounds!

[carlosfm]

Gents, I've had so many corruptions in the config.txt file that I keep a copy on my PC.
Even the first boot script of Raspbian corrupts the config.txt file, most of the times.
Why use FAT16 for the boot partition, why not FAT32?
FAT16 is prehistoric, I suspect it may be one of the problems here.

[dom]

Why use FAT16 for the boot partition, why not FAT32?
FAT16 is prehistoric, I suspect it may be one of the problems here.

On many sdcards (including mine), there is no problem with FAT16, so it's hard for us to prove that FAT32 is more reliable.

If you are suffering from corruption on the FAT partition, can you copy the files off the FAT partion (in Windows is fine), format the sdcard as FAT32 (again fine in windows - it won't affect the linux ext4 partition), then copy the files back on again. Let us know if that fixes the problem with file corruption.

[carlosfm]

Hi dom,

I was thinking about trying that, yes.
Will do it, when I have some time, and report back.

Thanks

[carlosfm]

Still on this FAT16 thing, it must start at the very beginning of the disk.
There are several references to this, like on Wikipedia:

https://en.wikipedia.org/wiki/FAT16#FAT16

Quote:
"A FAT file system is composed of four different sections:
The Reserved sectors, located at the very beginning.
The first reserved sector (logical sector 0) is the Boot Sector (aka Volume Boot Record (VBR)). It includes an area called the BIOS Parameter Block (with some basic file system information, in particular its type, and pointers to the location of the other sections) and usually contains the operating system's boot loader code."

I suspect the linux kernel is counting on this, as it should.
The problem is, at least on Raspbian (and some others), the FAT16 partition starts after a 4MB empty space.
I know this is made to optimize the reads and writes on the SD cards, but then what it seems to me is that FAT16 is totally unappropriated for the boot partition of the RPi.

I will try FAT32 for some time and report back.

[carlosfm]

Here's some feedback.
It is not a problem of FAT16.
I've made a backup of the boot FAT16 partition files, formated it with GParted to FAT32 (on Linux Mint, in my PC) and copied back the files.
Put the SD card (a Samsung 8GB Class 10) in the Pi and it booted without a problem.

Then I've made the torture (!) test, on the Pi.
I've edited the config.txt file with leafpad and added "aaa" inside a commented line (#aaahdmi_...).
File -> Save.
Just to be sure, I've edited the file again and it was fine, everything was intact, as I have saved.
Then, as on Raspbian the Shutdown on the LXDE menu doesn't work, I executed in the console:

sudo shutdown -h now

Restarted the Pi and it booted no problem.
But the text on the config.txt file was cut in half. Half of the text was missing, the file ended at about midway.
Once again, I had to go to my PC and put back the config.txt file as it was.

What puzzles me is that the sync command before the shutdown should not be necessary for many years, on Linux.
I have not tried to run sync before shutdown, propably it's a solution (and how many times?), but this doesn't seem stable at all...

[dom]

@carlosfm
Thanks for testing.

[AndrewS]

carlos - do you have another SD card you could test? Might be interesting to discover if the problem is with your RPi or your SD card Of course that still doesn't help explain why these corruptions are happening