Can you remove over_voltage and try. It shouldn't be needed for that very minor overclock, and would be interesting if it proves significant.milhouse wrote: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
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
Re: Overclocking
I've removed it, and I'm struggling to locate any corruption! Put it back, and next reboot, the partition is corrupt...dom wrote: Can you remove over_voltage and try. It shouldn't be needed for that very minor overclock, and would be interesting if it proves significant.
So it does appear to be significant (although please note I've only tested this for about 10-15 minutes).
For the past few hours I've been testing with current_limit_override enabled now that I've shorted the polyfuses on my Pi, and I've achieved stability in Raspbian at 1000/500/500/+6/+4 (+4 for over_voltage_sdram), this includes now being able to play Quake3 which previously forced a reboot. SD card corruption does not seem to occur with Raspbian (Transcend Class 10). OpenELEC is also stable with these same settings, but only when mounting root from USB memory stick - pretty much any overclock corrupts the SD card (Transcend Class 2 or Class 10) in OpenELEC. The only reason I mention this is to show that my Pi and PSU seem to be up to snuff when it comes to obtaining a decent overclock.
Could the difference in firmware be a factor (OpenELEC r11978 is using firmware from 16 Sep, while Raspbian dates from 20 Sep)?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
Nothing that seems relevent changed between start.elf from 16 Sep, and 20 Sep. You should be able to replace OpenELEC start.elf with latest one:milhouse wrote:I've removed it, and I'm struggling to locate any corruption! Put it back, and next reboot, the partition is corrupt...
So it does appear to be significant (although please note I've only tested this for about 10-15 minutes).
For the past few hours I've been testing with current_limit_override enabled now that I've shorted the polyfuses on my Pi, and I've achieved stability in Raspbian at 1000/500/500/+6/+4 (+4 for over_voltage_sdram), this includes now being able to play Quake3 which previously forced a reboot. SD card corruption does not seem to occur with Raspbian (Transcend Class 10). OpenELEC is also stable with these same settings, but only when mounting root from USB memory stick - pretty much any overclock corrupts the SD card (Transcend Class 2 or Class 10) in OpenELEC. The only reason I mention this is to show that my Pi and PSU seem to be up to snuff when it comes to obtaining a decent overclock.
Could the difference in firmware be a factor (OpenELEC r11978 is using firmware from 16 Sep, while Raspbian dates from 20 Sep)?
https://github.com/raspberrypi/firmware ... /start.elf
Can you try paying quake in your raspbian image, whole copying files in the background (to sdcard). Possibly quake doesn't write to sdcard much, compared to XBMC.
Re: Overclocking
I did try using the start.elf from Raspbian but it ended up as a bit of a mess - I'll try the one from github.dom wrote: Nothing that seems relevent changed between start.elf from 16 Sep, and 20 Sep. You should be able to replace OpenELEC start.elf with latest one:
https://github.com/raspberrypi/firmware ... /start.elf
OK, just did that with the following settings:dom wrote: Can you try paying quake in your raspbian image, whole copying files in the background (to sdcard). Possibly quake doesn't write to sdcard much, compared to XBMC.
Code: Select all
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4
current_limit_override=0x5A000020
There were no errors during the copy, and Quake played fine (if slowly!)
Once the copy had finished I exited from Quake, fsck'd the /dev/mmcblk0p2 partition (without making any changes - it was clean anyway), rebooted, and Raspbian came up fine with no errors - all the data is there, no corruption.
I've just finished running an md5sum on the transferred data, and all of the hashes are correct.
Re: Overclocking
OK, I downloaded start.elf from github, and it's returned mixed results.milhouse wrote: I did try using the start.elf from Raspbian but it ended up as a bit of a mess - I'll try the one from github.
I slapped it on a fresh OpenELEC r11978 image (Transcend Class 10, root on /dev/mmcblk0p2), and with the following overclock settings I didn't see any hint of corruption:
Code: Select all
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4
current_limit_override=0x5A000020
I then tried the following "low" settings:
Code: Select all
arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3
Code: Select all
Sep 23 12:59:48 openelec user.info kernel: [ 79.359253] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 12:59:51 openelec user.info kernel: [ 80.088838] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 13:03:33 openelec user.info kernel: [ 83.039619] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 13:03:33 openelec user.notice kernel: [ 305.128016] EXT4-fs (mmcblk0p2): error count: 6
Sep 23 13:03:33 openelec user.notice kernel: [ 305.128050] EXT4-fs (mmcblk0p2): initial error at 6: htree_dirblock_to_tree:587: inode 26: block 8730
Sep 23 13:03:33 openelec user.notice kernel: [ 305.128076] EXT4-fs (mmcblk0p2): last error at 7: ext4_mb_generate_buddy:739
On the basis of this limited testing, I'd say this github start.elf is an improvement on the version provided with OpenELEC r11978. However, it is very limited testing and I need to sit down and watch the footie...

Here is the version information for the start.elf I used for this test:
Code: Select all
root ~ # vcgencmd version
Sep 20 2012 22:38:16
Copyright (c) 2012 Broadcom
version 338528 (release)
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
I think we've got more than one reason for corruption going on here.
One plausible reason I can think of, is the BogoMips value reported is done early in boot, before the cpufreq driver is loaded, and so measures the stock (700MHz) frequency.
Now this is value is used elsewhere in linux when calibrating delays. E.g. the sdcard driver might call udelay(1) and expect to get a delay of at least one microsecond.
However if the ARM is now at 1GHz, it will only get a 0.7 microseconds, which could cause a problem.
To help investigate this, I've add a config.txt parameter, initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency.
This has the effect of setting the BogoMips value to the turbo frequency (1000MHz), and that has the side effect of making all delays at least as long as they should be.
So, if you have suffered sdcard corruption, please reimage. Run rpi-update. Set
initial_turbo=30
and enable overclock with raspi-config. Let me know if it behaves any better.
One plausible reason I can think of, is the BogoMips value reported is done early in boot, before the cpufreq driver is loaded, and so measures the stock (700MHz) frequency.
Now this is value is used elsewhere in linux when calibrating delays. E.g. the sdcard driver might call udelay(1) and expect to get a delay of at least one microsecond.
However if the ARM is now at 1GHz, it will only get a 0.7 microseconds, which could cause a problem.
To help investigate this, I've add a config.txt parameter, initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency.
This has the effect of setting the BogoMips value to the turbo frequency (1000MHz), and that has the side effect of making all delays at least as long as they should be.
So, if you have suffered sdcard corruption, please reimage. Run rpi-update. Set
initial_turbo=30
and enable overclock with raspi-config. Let me know if it behaves any better.
Re: Overclocking
Sticking my head in, bored with the Liverpool/United match... is there a version I can download for OpenELEC? ie. just the start.elf? Or do I need a kernel too?
Re: Overclocking
Thanks dom.
initial_turbo=30 seems to work for me.
So far I copied about 3 GB of data with 100% ARM usage. I'm using turbo mode with 1100MHz arm_freq.
No issues so far.
initial_turbo=30 seems to work for me.
So far I copied about 3 GB of data with 100% ARM usage. I'm using turbo mode with 1100MHz arm_freq.
No issues so far.
Last edited by john202 on Sun Sep 23, 2012 2:41 pm, edited 1 time in total.
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
Just replacing start.elf should be fine. The kernel hasn't changed.milhouse wrote:Sticking my head in, bored with the Liverpool/United match... is there a version I can download for OpenELEC? ie. just the start.elf? Or do I need a kernel too?
Re: Overclocking
Rather than use a delay until the cpufreq driver may or may not set an upper frequency, why not simply use the arm_freq defined by config.txt (defaulting to 700 if not specified) as the "bogomips" figure - would this be easier?dom wrote: To help investigate this, I've add a config.txt parameter, initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency.
This has the effect of setting the BogoMips value to the turbo frequency (1000MHz), and that has the side effect of making all delays at least as long as they should be.
Same link as before? I'll give it a go...dom wrote:Just replacing start.elf should be fine. The kernel hasn't changed.milhouse wrote:Sticking my head in, bored with the Liverpool/United match... is there a version I can download for OpenELEC? ie. just the start.elf? Or do I need a kernel too?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
Yes, it's a different version, but that link points to top of tree so should get the latest.milhouse wrote:same link as before? I'll give it a go...
Re: Overclocking
Not good news I'm afraid.
I booted OE r11978 with a "low" overclock (750/255). BogoMips is determined correctly as ~750 in /proc/cpuinfo. Three mmc-related errors appeared in log/messages. I rebooted, and the ext4 partition had been hosed.
@dom: I'm not sure if I should be testing with or without over_voltage=+3 any more... it's a valid setting so I don't see why not...
Will test some more later unless there's any more breakthroughs.
I booted OE r11978 with a "low" overclock (750/255). BogoMips is determined correctly as ~750 in /proc/cpuinfo. Three mmc-related errors appeared in log/messages. I rebooted, and the ext4 partition had been hosed.
@dom: I'm not sure if I should be testing with or without over_voltage=+3 any more... it's a valid setting so I don't see why not...

Will test some more later unless there's any more breakthroughs.

Code: Select all
Sep 23 15:00:53 openelec user.notice Boot: ### Starting Samba server ###
Sep 23 15:00:56 openelec daemon.err smbd[1136]: [2012/09/23 15:00:56.607395, 0] passdb/pdb_smbpasswd.c:248(startsmbfilepwent)
Sep 23 15:00:56 openelec daemon.err smbd[1136]: startsmbfilepwent_internal: file /var/run/smbpasswd did not exist. File successfully created.
Sep 23 15:00:59 openelec user.notice Boot: ### set cpu's to 'ondemand' ###
Sep 23 15:00:59 openelec user.info kernel: [ 22.429930] bcm2835-cpufreq: switching to governor ondemand
Sep 23 15:01:17 openelec user.info kernel: [ 22.429999] bcm2835-cpufreq: switching to governor ondemand
Sep 23 15:01:17 openelec user.err kernel: [ 40.106077] mmc0: final write to SD card still running
Sep 23 15:01:27 openelec user.info kernel: [ 46.044521] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 15:01:27 openelec user.err kernel: [ 50.123669] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 23 15:01:27 openelec user.err kernel: [ 50.124984] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 23 15:01:27 openelec user.notice Boot: ### SSH: generating SSH2 RSA key ###
Sep 23 15:01:40 openelec user.notice Boot: ### SSH: generating SSH2 DSA key ###
Sep 23 15:01:55 openelec user.notice Boot: ### Starting SSH Server ###
Sep 23 15:02:09 openelec user.info kernel: [ 50.514628] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 15:02:09 openelec user.info kernel: [ 91.914654] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 15:02:11 openelec user.info kernel: [ 92.274753] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 15:02:11 openelec user.info kernel: [ 94.104670] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Code: Select all
arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3
#over_voltage_sdram=4
initial_turbo=30
#current_limit_override=0x5A000020
Code: Select all
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 749.56
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Code: Select all
root ~ # vcgencmd version
Sep 23 2012 14:54:04
Copyright (c) 2012 Broadcom
version 338882 (release)
Re: Overclocking
I have a strange problem when using raspi-config that it doesnt did what i want. i'll configured ram split to 240/16 and overclocking to Turbo but when i reboot its still on ram split 192/64 without overclocking...
when i then check /boot/config.txt its ******up (last line is cuttet or very many " @ " appended) and no overclocking settings
Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux
when i edit /boot/config.txt and only add the overclock lines its again gone after reboot. only when i completely clear config.txt and add the lines it works
i also some other questions:
- what means "initial_turbo=30" ?
- and is there a way to get the current voltage of cpu/gpu?
when i then check /boot/config.txt its ******up (last line is cuttet or very many " @ " appended) and no overclocking settings

Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux
when i edit /boot/config.txt and only add the overclock lines its again gone after reboot. only when i completely clear config.txt and add the lines it works
i also some other questions:
- what means "initial_turbo=30" ?
- and is there a way to get the current voltage of cpu/gpu?
Re: Overclocking
milhouse wrote:OK, I downloaded start.elf from github, and it's returned mixed results.milhouse wrote: I did try using the start.elf from Raspbian but it ended up as a bit of a mess - I'll try the one from github.
I slapped it on a fresh OpenELEC r11978 image (Transcend Class 10, root on /dev/mmcblk0p2), and with the following overclock settings I didn't see any hint of corruption:I rebooted 3 times and cached about a dozen thumbnails each time - all good, no problems.Code: Select all
arm_freq=1000 core_freq=500 sdram_freq=500 over_voltage=6 over_voltage_sdram=4 current_limit_override=0x5A000020
I then tried the following "low" settings:and cached another dozen or so thumbnails, and there were no mmc errors in log/messages - it was all looking so good. Then, just as I was about to reboot, I saw the following in log/messages:Code: Select all
arm_freq=750 core_freq=255 sdram_freq=400 over_voltage=3
Rebooting resulted in a system that would not start (failure to mount /storage etc.).Code: Select all
Sep 23 12:59:48 openelec user.info kernel: [ 79.359253] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000) Sep 23 12:59:51 openelec user.info kernel: [ 80.088838] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000) Sep 23 13:03:33 openelec user.info kernel: [ 83.039619] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000) Sep 23 13:03:33 openelec user.notice kernel: [ 305.128016] EXT4-fs (mmcblk0p2): error count: 6 Sep 23 13:03:33 openelec user.notice kernel: [ 305.128050] EXT4-fs (mmcblk0p2): initial error at 6: htree_dirblock_to_tree:587: inode 26: block 8730 Sep 23 13:03:33 openelec user.notice kernel: [ 305.128076] EXT4-fs (mmcblk0p2): last error at 7: ext4_mb_generate_buddy:739
On the basis of this limited testing, I'd say this github start.elf is an improvement on the version provided with OpenELEC r11978. However, it is very limited testing and I need to sit down and watch the footie...
Here is the version information for the start.elf I used for this test:I'll do more testing in OpenELEC r11978 at high and low overclocks later on today to confirm what I've seen so far....Code: Select all
root ~ # vcgencmd version Sep 20 2012 22:38:16 Copyright (c) 2012 Broadcom version 338528 (release)
Try a different sd card. Even thought the Transcend class 10 is listed as compatible on the wiki. It suffered sd card corruption pre-09/21/12 issues.
Re: Overclocking
I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).meigrafd wrote: when i then check /boot/config.txt its ******up (last line is cuttet or very many " @ " appended) and no overclocking settings![]()
Using arm1000, core500, dram450, ovolt5, current override.
I also have trascend class10 card so wonder if it is that... I'm going to experiment with the core to see if it is stable writng to the card. If i clock back to 700 then it absolutely fine doing updates and boot config etc.
Cheers,
Kev
--
http://www.kevs3d.co.uk/dev - HTML5 canvas games, demos and utils.
http://www.kevs3d.co.uk/dev - HTML5 canvas games, demos and utils.
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
Can you try this:kevs3d wrote:I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).
Using arm1000, core500, dram450, ovolt5, current override.
I also have trascend class10 card so wonder if it is that... I'm going to experiment with the core to see if it is stable writng to the card. If i clock back to 700 then it absolutely fine doing updates and boot config etc.
http://www.raspberrypi.org/phpBB3/viewt ... 25#p180099
Re: Overclocking
im currently using a class4 platinum 4gbkevs3d wrote: I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).
Using arm1000, core500, dram450, ovolt5, current override.
I also have trascend class10 card so wonder if it is that...
when i'll clear config.txt and only add the 5 overclock lines
Code: Select all
force_turbo=0
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
Re: Overclocking
I'll also be testing with a Class 2 which exhibits similar problems to the Class 10, but for now one card at a time is about all I can cope with...stevotdo wrote:Try a different sd card. Even thought the Transcend class 10 is listed as compatible on the wiki. It suffered sd card corruption pre-09/21/12 issues.

As for any prior issues, I can't say I've experienced anything negative. Prior to the introduction of the dynamic overclock feature, these Class 10 cards have been as good as gold, at least in my experience anyway, with OpenELEC (which I test frequently, whenever there is a new testbuild) and also (but less often) Rasbpmc.
Re: Overclocking
@dom:
(Testing with a Transcend 8GB Class 10 SD Card)
1) Booting this latest "delayed turbo" start.elf using OE r11978 and with settings at 750/255/+3 is a bit hit & miss, with a fresh image the R-Pi never makes it to the GUI (the Pi can be ping'ed etc., but no sshd and just a blank display) so the device has to be power cycled, then typically the GUI comes up at the second attempt. Since this power cycle can leave the ext4 partition in a corrupt state, I first clean boot with 750/250/+3 settings as this configuration seems to boot first time every time, for some strange reason.
2) At 720/250/+3, with XBMC idle at the menu, I used an ssh session to transfer 0.5GB of data (1 directory, 10 files) over NFS to the SD card. Once complete, e2fsck checked out clean. OpenELEC rebooted without a problem on 3 occasions.
3) At 750/255/+3, I again commenced the transfer of the same 0.5GB data to the SD card, and this resulted in catastrophic corruption of the ext4 partition, see log (pastebin). I have indicated in the log the approximate point at which the data transfer begins - it's only a simple cp of the directory over NFS. Rebooting this device was obviously futile. This test case is easily repeatable (for me, anyway).
4) At 1000/500/500/+6/+4, the freshly imaged SD card booted first time without a hitch (as per 750/250, but not 750/255), and the 0.5GB transfer over NFS commenced, ending after only 68MB had transferred when the Pi stopped responding to the network, keyboard/mouse and IR receiver but XBMC was still active on the display (click updating, RSS feed scrolling etc.). I'm guessing from the message in the log below, that the USB bus shut down completely (I've included the output of lsusb -v in case it's helpful). Strange that I had no problem transferring double this amount of data while playing a game of Quake in Raspbian!
A power cycle was required, and the system came up clean. I reverted to testing SD card writes by caching thumbnails, I must have cached over 20 thumbnails (coverart + fanart) without any errors appearing in the log, and the device was able to reboot on three consecutive occasions without any SD card corruption.
(Testing with a Transcend 8GB Class 10 SD Card)
1) Booting this latest "delayed turbo" start.elf using OE r11978 and with settings at 750/255/+3 is a bit hit & miss, with a fresh image the R-Pi never makes it to the GUI (the Pi can be ping'ed etc., but no sshd and just a blank display) so the device has to be power cycled, then typically the GUI comes up at the second attempt. Since this power cycle can leave the ext4 partition in a corrupt state, I first clean boot with 750/250/+3 settings as this configuration seems to boot first time every time, for some strange reason.
2) At 720/250/+3, with XBMC idle at the menu, I used an ssh session to transfer 0.5GB of data (1 directory, 10 files) over NFS to the SD card. Once complete, e2fsck checked out clean. OpenELEC rebooted without a problem on 3 occasions.
3) At 750/255/+3, I again commenced the transfer of the same 0.5GB data to the SD card, and this resulted in catastrophic corruption of the ext4 partition, see log (pastebin). I have indicated in the log the approximate point at which the data transfer begins - it's only a simple cp of the directory over NFS. Rebooting this device was obviously futile. This test case is easily repeatable (for me, anyway).
4) At 1000/500/500/+6/+4, the freshly imaged SD card booted first time without a hitch (as per 750/250, but not 750/255), and the 0.5GB transfer over NFS commenced, ending after only 68MB had transferred when the Pi stopped responding to the network, keyboard/mouse and IR receiver but XBMC was still active on the display (click updating, RSS feed scrolling etc.). I'm guessing from the message in the log below, that the USB bus shut down completely (I've included the output of lsusb -v in case it's helpful). Strange that I had no problem transferring double this amount of data while playing a game of Quake in Raspbian!
A power cycle was required, and the system came up clean. I reverted to testing SD card writes by caching thumbnails, I must have cached over 20 thumbnails (coverart + fanart) without any errors appearing in the log, and the device was able to reboot on three consecutive occasions without any SD card corruption.
Code: Select all
root ~ # tail -f log/messages
Sep 23 19:37:17 openelec user.info kernel: [ 21.734552] bcm2835-cpufreq: switching to governor ondemand
Sep 23 19:37:23 openelec user.notice Boot: ### SSH: generating SSH2 RSA key ###
Sep 23 19:37:26 openelec user.notice Boot: ### SSH: generating SSH2 DSA key ###
Sep 23 19:37:33 openelec user.info kernel: [ 21.734570] bcm2835-cpufreq: switching to governor ondemand
Sep 23 19:37:33 openelec user.notice Boot: ### Starting SSH Server ###
Sep 23 19:37:34 openelec user.info kernel: [ 37.294176] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000)
Sep 23 19:37:35 openelec user.info kernel: [ 38.014331] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)
Sep 23 19:37:37 openelec user.info kernel: [ 39.854193] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000)
Sep 23 19:37:37 openelec user.info kernel: [ 41.014345] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)
Sep 23 19:37:40 openelec user.info kernel: [ 41.394196] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000)
Sep 23 19:39:13 openelec user.info kernel: [ 44.874301] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)
Sep 23 19:39:13 openelec user.warn kernel: [ 137.257972] usb 1-1.2: input irq status -5 received
Code: Select all
root ~ # lsusb -v
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.02
iManufacturer 3 Linux 3.2.29 dwc_otg_hcd
iProduct 2 DWC OTG Controller
iSerial 1 bcm2708_usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0008
Ganged power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Device Status: 0x0001
Self Powered
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 2 TT per port
bMaxPacketSize0 64
idVendor 0x0424 Standard Microsystems Corp.
idProduct 0x9512
bcdDevice 2.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 1 Single TT
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 2 TT per port
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 1 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0303 lowspeed power enable connect
Port 3: 0000.0303 lowspeed power enable connect
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 1
bMaxPacketSize0 64
idVendor 0x0424 Standard Microsystems Corp.
idProduct 0xec00
bcdDevice 2.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 4
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 1
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Bus 001 Device 004: ID 0518:0001 EzKEY Corp. USB to PS2 Adaptor v1.09
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0518 EzKEY Corp.
idProduct 0x0001 USB to PS2 Adaptor v1.09
bcdDevice 0.01
iManufacturer 1 Composite USB PS2 Converter
iProduct 2 USB to PS2 Adaptor v1.12
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 2 USB to PS2 Adaptor v1.12
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 64
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 102
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 005: ID 05a4:9881 Ortek Technology, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x05a4 Ortek Technology, Inc.
idProduct 0x9881
bcdDevice 1.20
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 63
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 208
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0005 1x 5 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Re: Overclocking
Getting these quite often now when playing back media on the OpenELEC system with latest start.elf at 1000/500/500/+6/+4:
The system appears to hang (playback freezes), but it probably is available, just that no USB I/O (network, keyboard/mouse, IR) is possible.
I don't recall seeing this USB issue prior to this new start.elf - I haven't seen it in Raspbian (with the default - as supplied - 2012-09-18 start.elf), nor in OpenELEC when using the default r11978 start.elf and mounting root from a USB memory stick to avoid SD corruption at these same high overclock settings).
Code: Select all
Sep 23 21:39:39 openelec user.warn kernel: [ 101.595294] usb 1-1.3: input irq status -5 received
Sep 23 21:40:21 openelec user.warn kernel: [ 142.877388] usb 1-1.2: input irq status -5 received
I don't recall seeing this USB issue prior to this new start.elf - I haven't seen it in Raspbian (with the default - as supplied - 2012-09-18 start.elf), nor in OpenELEC when using the default r11978 start.elf and mounting root from a USB memory stick to avoid SD corruption at these same high overclock settings).
Re: Overclocking
@Dom: I've gone back to Raspbian 2012-09-18 (vcgencmd version version 337601, Sep 18 2012 01:45:27) to repeat the data transfer tests I performed previously at 1000/500/500/+6/+4 with Quake running concurrently, and I've discovered that Raspbian can be made to "hang" - but only when Quake is NOT running.milhouse wrote:Getting these quite often now when playing back media on the OpenELEC system with latest start.elf at 1000/500/500/+6/+4:
The system appears to hang (playback freezes), but it probably is available, just that no USB I/O (network, keyboard/mouse, IR) is possible.Code: Select all
Sep 23 21:39:39 openelec user.warn kernel: [ 101.595294] usb 1-1.3: input irq status -5 received Sep 23 21:40:21 openelec user.warn kernel: [ 142.877388] usb 1-1.2: input irq status -5 received
I don't recall seeing this USB issue prior to this new start.elf - I haven't seen it in Raspbian (with the default - as supplied - 2012-09-18 start.elf), nor in OpenELEC when using the default r11978 start.elf and mounting root from a USB memory stick to avoid SD corruption at these same high overclock settings).

With the original start.elf, Raspbian will consistently complete the data transfer without fail when Quake is being run AT THE SAME TIME (which was the purpose of the original test) - testing with dd to /dev/null, the Pi will achieve about 11.5MB/s over NFS (not bad for a 10/100 connection!):
Code: Select all
pi@raspberrypi ~ $ dd if=/freenas/data/pi.test/largefile.dat of=/dev/null bs=1M
457+1 records in
457+1 records out
479493658 bytes (479 MB) copied, 41.536 s, 11.5 MB/s
pi@raspberrypi ~ $ dd if=/freenas/data/pi.test/largefile.dat of=/dev/null bs=1M
457+1 records in
457+1 records out
479493658 bytes (479 MB) copied, 41.3872 s, 11.6 MB/s
pi@raspberrypi ~ $ vcgencmd version
Sep 18 2012 01:45:27
Copyright (c) 2012 Broadcom
version 337601 (release)
It's not even necessary to write to the SD card when performing this test so the SD card can be eliminated as a variable - simply dd'ing a large file across the network to /dev/null is sufficient to hang Raspbian (struggling to see precisely why though, as there's nothing being written to the logs - I'm guessing it's a problem with the USB bus).
Presumably while Quake is also running, the additional load from Quake prevents some other part of the system from being swamped/overloaded by the USB activity. With Quake running, the IRQ load during the "dd to /dev/null" transfer is about 7,500-8,000 IRQ/s, but when Quake is not running the IRQ load for the same transfer can peak at about 11,200 IRQ/s. With only Quake running (and no data transfer) the IRQ load is about 900 IRQ/second.
I'd guess this is a separate issue from the SD Card corruption - is anyone else able to confirm this USB behaviour when overclocked?
Re: Overclocking
Hmmm... this isn't so easy to reproduce, not even with OpenELEC which has now decided to remain stable during my most recent tests.... what a PITA. 

-
- Posts: 2
- Joined: Mon Sep 24, 2012 8:41 am
Re: Overclocking
Forgive me - I'm not 100% up to speed with how all the bits (slices?) of the Pi hang together...
Is the SD card connected through the USB bus in a similar manner to the networking?
I'm wondering if it's possible that the problems being seen aren't necessarily coming from the overclocks and if they might be symptoms of USB issues? I'm sure I read that some USB fixes had gone in at the same time as the turbo mode stuff.
Perhaps those 2 changes are masking each other, possibly the overclocking exacerbating another issue.
I'm not in a position to do so at the moment but,is anybody able to, and think it worthwhile, to do some testing with the USB fixes disabled?
Please ignor eme if I'm talking nonsense, I just wanted to throw the idea out there.
Is the SD card connected through the USB bus in a similar manner to the networking?
I'm wondering if it's possible that the problems being seen aren't necessarily coming from the overclocks and if they might be symptoms of USB issues? I'm sure I read that some USB fixes had gone in at the same time as the turbo mode stuff.
Perhaps those 2 changes are masking each other, possibly the overclocking exacerbating another issue.
I'm not in a position to do so at the moment but,is anybody able to, and think it worthwhile, to do some testing with the USB fixes disabled?
Please ignor eme if I'm talking nonsense, I just wanted to throw the idea out there.
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5734
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Overclocking
No.butlerpeter wrote:Is the SD card connected through the USB bus in a similar manner to the networking?
Re: Overclocking
I'm using forceturbo so I assume that won't matter? I also have a Kingston class 4 card with an identical image that I'm about to see if i can reproduce the issue on - i'm testing up to arm1100 ovolt8 with that also.dom wrote:Can you try this:kevs3d wrote:I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).
Using arm1000, core500, dram450, ovolt5, current override.
I also have trascend class10 card so wonder if it is that... I'm going to experiment with the core to see if it is stable writng to the card. If i clock back to 700 then it absolutely fine doing updates and boot config etc.
http://www.raspberrypi.org/phpBB3/viewt ... 25#p180099
Is there anything that can be one to "tame" the class 10 cards if it does prove to be the problem...?
--
http://www.kevs3d.co.uk/dev - HTML5 canvas games, demos and utils.
http://www.kevs3d.co.uk/dev - HTML5 canvas games, demos and utils.