Re: Updating to the 2012-09-18-wheezy-raspbian image
After the update & upgrade, upon reboot I still see:
Linux raspberrypi 3.1.9-cutdown-aufs #23 PREEMPT Mon Aug 13 15:20:21 CEST 2012 armv61
Is there any hope for me?
Linux raspberrypi 3.1.9-cutdown-aufs #23 PREEMPT Mon Aug 13 15:20:21 CEST 2012 armv61
Is there any hope for me?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5706
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Updating to the 2012-09-18-wheezy-raspbian image
That's not the default raspbian/wheezy kernel. Did you start from a different image?Joe! wrote:After the update & upgrade, upon reboot I still see:
Linux raspberrypi 3.1.9-cutdown-aufs #23 PREEMPT Mon Aug 13 15:20:21 CEST 2012 armv61
Is there any hope for me?
Re: Updating to the 2012-09-18-wheezy-raspbian image
I started from the default kernel but used Hexxeh's firmware updater. I have tried using it multiple times since that first successful usage, but alas, no updates seem to stick. I do see other version directories in the /boot folder.dom wrote:That's not the default raspbian/wheezy kernel. Did you start from a different image?Joe! wrote:After the update & upgrade, upon reboot I still see:
Linux raspberrypi 3.1.9-cutdown-aufs #23 PREEMPT Mon Aug 13 15:20:21 CEST 2012 armv61
Is there any hope for me?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5706
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Updating to the 2012-09-18-wheezy-raspbian image
I believe you are using Berryboot. You might need to uninstall that first, or start with a clean image.Joe! wrote:I started from the default kernel but used Hexxeh's firmware updater. I have tried using it multiple times since that first successful usage, but alas, no updates seem to stick. I do see other version directories in the /boot folder.
- williamhbell
- Posts: 291
- Joined: Mon Dec 26, 2011 5:13 pm
- Contact: Website Twitter
Re: Updating to the 2012-09-18-wheezy-raspbian image
Hi,
Having started from the new image, all seems to be good. The performance is much better. Thanks to all those involved. Viewing the BBC web site with Chromium works quite well.
Best regards, Will
Having started from the new image, all seems to be good. The performance is much better. Thanks to all those involved. Viewing the BBC web site with Chromium works quite well.
Best regards, Will
-
- Posts: 16
- Joined: Wed May 30, 2012 6:11 pm
Re: Updating to the 2012-09-18-wheezy-raspbian image
I have the same problem here. Everything seemed to update just fine, but after I shutdown when I reboot again I get no video.
How can me and sghazagh recover from this so we can use it again?
Thanks for any help
How can me and sghazagh recover from this so we can use it again?
Thanks for any help
binoyxj wrote:Make sure you execute this after update n upgrade,sghazagh wrote:I have used "Apt-get update && apt-get upgrade" and everything went well but after reboot it is not coming up!
Please help
Code: Select all
sudo apt-get install raspberrypi* raspi-config
-
- Posts: 148
- Joined: Thu Aug 02, 2012 7:08 pm
Re: Updating to the 2012-09-18-wheezy-raspbian image
I am not sure, if this belongs here, but after this upgrade, my touchscreen does not work anymore. It worked out of the box with the previous image version.
The touch device is found but i manually have to do "modprobe hid_multitouch" to get it to work. But it still is not calibrated. Before the update I did not have to calibrate.
Are there any driver changes I could start investigating with?
The touch device is found but i manually have to do "modprobe hid_multitouch" to get it to work. But it still is not calibrated. Before the update I did not have to calibrate.
Are there any driver changes I could start investigating with?
Pitendo - Case And Emulator Project - http://edv-huber.com/index.php/problemloesungen/12-pitendo
-
- Posts: 510
- Joined: Thu Aug 02, 2012 9:09 pm
- Location: UK
Re: Updating to the 2012-09-18-wheezy-raspbian image
I just downloaded the new Raspbian image (September 2012) and flashed a new card (class 10 as opposed to my original class 4) with it, and set the overclocking to 'Turbo' in the initial raspi-config - have to know whether it works, so no sense in holding back.
I don't have Quake III handy for stress testing but one thing I have noticed a dramatic difference in - Midori. With the old image I kept loyally trying to do stuff like web browsing on the Pi using Midori, but it was almost unusably slow, especially when trying to type a message into this forum - typically I'd hit a key and the letter would appear on the screen up to half a second later, although I did find that if I just typed at full speed everything I typed was buffered and all my text - hopefully minus errors - would eventually appear on the screen.
Totally different experience with this build: I'm using the Pi / Midori to type this now and there is now no discernible delay between my typing a character and it being echoed on the screen. One theory that I had about this earlier was that the real-time spelling checker might be creating a lot of overhead, but it made no difference when I turned it off when using the previous image. With this build, typing text into this forum is now just as slick as it is on any other computer.
It's also possible that the access speed of the original Sandisk class 4 card I was using was dragging everything down. I'll try flashing that old card with the new build, and see if it is noticeably slower on that card.
I don't have Quake III handy for stress testing but one thing I have noticed a dramatic difference in - Midori. With the old image I kept loyally trying to do stuff like web browsing on the Pi using Midori, but it was almost unusably slow, especially when trying to type a message into this forum - typically I'd hit a key and the letter would appear on the screen up to half a second later, although I did find that if I just typed at full speed everything I typed was buffered and all my text - hopefully minus errors - would eventually appear on the screen.
Totally different experience with this build: I'm using the Pi / Midori to type this now and there is now no discernible delay between my typing a character and it being echoed on the screen. One theory that I had about this earlier was that the real-time spelling checker might be creating a lot of overhead, but it made no difference when I turned it off when using the previous image. With this build, typing text into this forum is now just as slick as it is on any other computer.
It's also possible that the access speed of the original Sandisk class 4 card I was using was dragging everything down. I'll try flashing that old card with the new build, and see if it is noticeably slower on that card.
-
- Posts: 16
- Joined: Wed May 30, 2012 6:11 pm
Re: Updating to the 2012-09-18-wheezy-raspbian image
Fixed it with a fresh raspbian install for anyone else having a similar problem
tokyostormdrain wrote:I have the same problem here. Everything seemed to update just fine, but after I shutdown when I reboot again I get no video.
How can me and sghazagh recover from this so we can use it again?
Thanks for any help
binoyxj wrote:Make sure you execute this after update n upgrade,sghazagh wrote:I have used "Apt-get update && apt-get upgrade" and everything went well but after reboot it is not coming up!
Please help
Code: Select all
sudo apt-get install raspberrypi* raspi-config
-
- Posts: 510
- Joined: Thu Aug 02, 2012 9:09 pm
- Location: UK
Re: Updating to the 2012-09-18-wheezy-raspbian image
Just strolling by.. I'm using that very card myself - Transcend 8GB class 10, and running at the highest (turbo) level of overclock as set from Raspi-Config. Mine was flashed with a brand new download of the image. I haven't (yet) experienced the problems you have described.Ed Raket wrote:I did a fresh install of the new image twice (with a SD card format inbetween) and all is well until i set overclock and reboot, then my config.txt is intantly messed up. Maybe this specific SD card is sort of.. sensitive?dom wrote:Is this from an updated older image, or a new intall?Ed Raket wrote:Me to, overclock corrupts my SD card (config.txt edit's itself...). This issue was solved for a while but it seems to be back? Card= Transcend 8gb class 10
It could be the corruption happened from an older kernel, and you are just seeing the result when you try writing to the boot partition.
A reimage (or format the FAT partion, then copy the files back on) may help.
Re: Updating to the 2012-09-18-wheezy-raspbian image
Please add the default clock options to a wiki / FAQ somewhere
“None” “700MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt”
“Modest” “800MHz ARM, 300MHz core, 400MHz SDRAM, 0 overvolt”
“Medium” “900MHz ARM, 333MHz core, 450MHz SDRAM, 2 overvolt”
“High” “950MHz ARM, 450MHz core, 450MHz SDRAM, 6 overvolt”
“Turbo” “1000MHz ARM, 500MHz core, 500MHz SDRAM, 6 overvolt”
“None” “700MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt”
“Modest” “800MHz ARM, 300MHz core, 400MHz SDRAM, 0 overvolt”
“Medium” “900MHz ARM, 333MHz core, 450MHz SDRAM, 2 overvolt”
“High” “950MHz ARM, 450MHz core, 450MHz SDRAM, 6 overvolt”
“Turbo” “1000MHz ARM, 500MHz core, 500MHz SDRAM, 6 overvolt”
Re: Updating to the 2012-09-18-wheezy-raspbian image
Then it would seem that the Pi itself scrambles the SD card when overclocked... interestingSiriusHardware wrote:Just strolling by.. I'm using that very card myself - Transcend 8GB class 10, and running at the highest (turbo) level of overclock as set from Raspi-Config. Mine was flashed with a brand new download of the image. I haven't (yet) experienced the problems you have described.Ed Raket wrote: I did a fresh install of the new image twice (with a SD card format inbetween) and all is well until i set overclock and reboot, then my config.txt is intantly messed up. Maybe this specific SD card is sort of.. sensitive?

Re: Updating to the 2012-09-18-wheezy-raspbian image
I'm definitely seeing SD card scrambling when using OpenELEC r11955 overclocked. Not all the time, and prior to the scrambling (of the ext4 partition) there is no apparent instability - it only becomes obvious when trying to reboot (having selected Reboot in the GUI, not due to a crash etc.) and the ext4 partition can't be mounted because it's been trashed.Ed Raket wrote: Then it would seem that the Pi itself scrambles the SD card when overclocked... interesting
Re: Updating to the 2012-09-18-wheezy-raspbian image
I'm seeing errors such as the following in OpenELEC r11955 (/storage/log/messages) when navigating the GUI (overclock settings: arm:900/core:400/sdram:450/volts:+3):
Transcend 8GB Class 10.
Code: Select all
Sep 21 08:09:26 openelec user.crit kernel: [ 610.799597] EXT4-fs error (device mmcblk0p2): ext4_lookup:1050: inode #262657: comm ls: deleted inode referenced: 262691
Sep 21 08:09:26 openelec user.crit kernel: [ 610.807949] EXT4-fs error (device mmcblk0p2): ext4_lookup:1050: inode #262657: comm ls: deleted inode referenced: 262689
Sep 21 08:10:06 openelec user.crit kernel: [ 650.047908] EXT4-fs error (device mmcblk0p2): ext4_lookup:1050: inode #262657: comm syslogd: deleted inode referenced: 262691
Sep 21 08:10:37 openelec user.info kernel: [ 681.283901] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
Sep 21 08:10:53 openelec user.info kernel: [ 681.662374] bcm2835-cpufreq: Freq 900000->700000 (min=700000 max=900000 target=700000 request=700000)
Sep 21 08:10:54 openelec user.info kernel: [ 697.702271] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
Sep 21 08:11:02 openelec user.info kernel: [ 698.832491] bcm2835-cpufreq: Freq 900000->700000 (min=700000 max=900000 target=700000 request=700000)
Sep 21 08:11:13 openelec user.info kernel: [ 706.872241] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
Sep 21 08:11:14 openelec user.info kernel: [ 717.502309] bcm2835-cpufreq: Freq 900000->700000 (min=700000 max=900000 target=700000 request=700000)
Sep 21 08:11:16 openelec user.info kernel: [ 718.222271] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
Sep 21 08:11:16 openelec user.err kernel: [ 720.167782] mmc0: final write to SD card still running
Sep 21 08:11:26 openelec user.info kernel: [ 723.992440] bcm2835-cpufreq: Freq 900000->700000 (min=700000 max=900000 target=700000 request=700000)
Sep 21 08:11:26 openelec user.err kernel: [ 730.181454] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 08:11:26 openelec user.err kernel: [ 730.182699] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 08:11:28 openelec user.info kernel: [ 730.842487] bcm2835-cpufreq: Freq 700000->900000 (min=700000 max=900000 target=900000 request=900000)
Sep 21 08:11:28 openelec user.err kernel: [ 732.886394] mmc0: final write to SD card still running
Sep 21 08:11:38 openelec user.info kernel: [ 737.712403] bcm2835-cpufreq: Freq 900000->700000 (min=700000 max=900000 target=700000 request=700000)
Sep 21 08:11:38 openelec user.err kernel: [ 742.901446] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 08:11:38 openelec user.err kernel: [ 742.902629] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Re: Updating to the 2012-09-18-wheezy-raspbian image
I tried a new install on an other SD card i found, it is an older Sandisk "extreme III" 2gb... And the "scrambling" problem is gone! Turbo mode works fine, no corruption of the filesystem anymore
Maybe we should open a wiki section for "turbo mode compatible" SD card's?

Maybe we should open a wiki section for "turbo mode compatible" SD card's?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5706
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Updating to the 2012-09-18-wheezy-raspbian image
If anyone has corruption problems with overclock, can you try manually lowering:
arm_freq to 700
core_freq to 250
sdram_freq to 400
in config.txt one at a time to try to determine which part of the overclock is causing the problem.
arm_freq to 700
core_freq to 250
sdram_freq to 400
in config.txt one at a time to try to determine which part of the overclock is causing the problem.
Re: Updating to the 2012-09-18-wheezy-raspbian image
Hey folks,
first of all I want to thank you for implementing the turbo mode. Free extra performance!
I'v already made a youtube video (in German) about it http://www.youtube.com/watch?v=6z5wU11lTr0
But now I've encountered a problem. The first switch to the 900 MHz boost level worked (as shown in the video), then I tried 1 GHz, but the RasPi started with 700 MHz again. When I try to another level, it just doesn't work, the cpu frequency remains at 700 MHz. I'm selecting a speed, reboot and then the PI still runs at the same speed. Is it a bug or a feature?
Or am I doing something wrong?
first of all I want to thank you for implementing the turbo mode. Free extra performance!

But now I've encountered a problem. The first switch to the 900 MHz boost level worked (as shown in the video), then I tried 1 GHz, but the RasPi started with 700 MHz again. When I try to another level, it just doesn't work, the cpu frequency remains at 700 MHz. I'm selecting a speed, reboot and then the PI still runs at the same speed. Is it a bug or a feature?

Re: Updating to the 2012-09-18-wheezy-raspbian image
Originally tried to upgrade from an earlier image (July) and failed to reboot. Some kind of corrupted config file so I did a fresh install.
Works like a dream on turbo. Much faster and I love the new CPUfreq and temp options in the taskbar.
Never thought I'd see a turbo boost option on a £30 pc. Well done to the team!
Works like a dream on turbo. Much faster and I love the new CPUfreq and temp options in the taskbar.
Never thought I'd see a turbo boost option on a £30 pc. Well done to the team!
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5706
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Updating to the 2012-09-18-wheezy-raspbian image
How are you measuring the frequency? It only increases when CPU is busy.der-don wrote:But now I've encountered a problem. The first switch to the 900 MHz boost level worked (as shown in the video), then I tried 1 GHz, but the RasPi started with 700 MHz again. When I try to another level, it just doesn't work, the cpu frequency remains at 700 MHz. I'm selecting a speed, reboot and then the PI still runs at the same speed. Is it a bug or a feature?Or am I doing something wrong?
Re: Updating to the 2012-09-18-wheezy-raspbian image
With these default profiles and 'Turbo Mode',
1. Why does the config.txt file not put in limits such as: "arm_freq_min" and "over_voltage_min"?
Is it automatic in the cpufreq driver?
2. Why does it not include dynamic RAM frequency or overvolt settings: "over_voltage_sdram"?
3. Would it be safe to add the RAM settings (except "sdram_freq=500" - already present) and overvolting the RAM WITHOUT VOIDING WARRANTY? and having it dynamically changing?
1. Why does the config.txt file not put in limits such as: "arm_freq_min" and "over_voltage_min"?
Is it automatic in the cpufreq driver?
2. Why does it not include dynamic RAM frequency or overvolt settings: "over_voltage_sdram"?
3. Would it be safe to add the RAM settings (except "sdram_freq=500" - already present) and overvolting the RAM WITHOUT VOIDING WARRANTY? and having it dynamically changing?
Re: Updating to the 2012-09-18-wheezy-raspbian image
I don't have corruption with Raspbian (which completed a quake compile at 1000/500/450/+6), but I do with OpenELEC r11955 with much lower ARM settings. The corruption would appear to be due to SD card errors (in part, at least).dom wrote:If anyone has corruption problems with overclock, can you try manually lowering:
arm_freq to 700
core_freq to 250
sdram_freq to 400
in config.txt one at a time to try to determine which part of the overclock is causing the problem.
I can't identify the required settings with any certainty, but 800/450/450/+3 just did it for me. The following log messages relate to a a situation where I booted OpenELEC with the aforementioned settings, browsed into Video -> Files and chose an NFS media source (it was movies, so needed to cache thumbnails etc.), scrolled through a handful of the box sets - all OK, no errors or problems. I attempted to reboot the device but OpenELEC instead just restarted XBMC, and then the SD errors began to appear...
Here's the first part of the log, no errors...
Code: Select all
root ~ # tail -f log/messages
Sep 21 12:04:25 openelec daemon.info connmand[906]: Client-Country: GB
Sep 21 12:04:25 openelec daemon.info connmand[906]: eth0 {del} route 81.169.141.235 gw 192.168.0.1 scope 0 <UNIVERSE>
Sep 21 12:04:25 openelec daemon.notice dbus[879]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper)
Sep 21 12:04:26 openelec daemon.info polkitd[1151]: started daemon version 0.104 using authority implementation `local' version `0.104'
Sep 21 12:04:26 openelec daemon.notice dbus[879]: [system] Successfully activated service 'fi.w1.wpa_supplicant1'
Sep 21 12:04:26 openelec daemon.notice dbus[879]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Sep 21 12:04:28 openelec daemon.err smbd[1202]: [2012/09/21 12:04:28.750474, 0] passdb/pdb_smbpasswd.c:248(startsmbfilepwent)
Sep 21 12:04:28 openelec daemon.err smbd[1202]: startsmbfilepwent_internal: file /var/run/smbpasswd did not exist. File successfully created.
Sep 21 12:04:29 openelec user.notice Boot: ### set cpu's to 'conservative' ###
Sep 21 12:04:29 openelec user.info kernel: [ 23.995314] bcm2835-cpufreq: switching to governor conservative
Sep 21 12:04:51 openelec user.info kernel: [ 23.995338] bcm2835-cpufreq: switching to governor conservative
Sep 21 12:04:51 openelec user.info kernel: [ 46.551071] bcm2835-cpufreq: Freq 800000->760000 (min=700000 max=800000 target=760000 request=760000)
Sep 21 12:04:53 openelec user.info kernel: [ 46.891139] bcm2835-cpufreq: Freq 760000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:04:53 openelec user.info kernel: [ 48.001131] bcm2835-cpufreq: Freq 800000->760000 (min=700000 max=800000 target=760000 request=760000)
Sep 21 12:04:58 openelec user.info kernel: [ 48.332690] bcm2835-cpufreq: Freq 760000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:04:58 openelec user.info kernel: [ 53.853514] bcm2835-cpufreq: switching to governor ondemand
Sep 21 12:04:59 openelec user.info kernel: [ 53.853539] bcm2835-cpufreq: switching to governor ondemand
Sep 21 12:05:18 openelec user.info kernel: [ 54.221811] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:05:20 openelec user.info kernel: [ 73.621848] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:06:30 openelec user.info kernel: [ 75.431813] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:06:31 openelec user.info kernel: [ 145.531756] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:06:53 openelec user.info kernel: [ 146.291843] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:06:54 openelec user.info kernel: [ 168.382738] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:01 openelec user.info kernel: [ 169.121886] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:02 openelec user.info kernel: [ 176.791825] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:05 openelec user.info kernel: [ 177.171865] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:06 openelec user.info kernel: [ 180.792296] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:08 openelec user.info kernel: [ 181.151760] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:08 openelec user.info kernel: [ 182.961809] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:09 openelec user.info kernel: [ 183.321818] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:10 openelec user.info kernel: [ 184.762235] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:10 openelec user.info kernel: [ 185.121959] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:11 openelec user.info kernel: [ 185.481910] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:11 openelec user.info kernel: [ 186.202234] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:14 openelec user.info kernel: [ 186.561871] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:23 openelec user.info kernel: [ 189.801876] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:24 openelec user.info kernel: [ 198.911843] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:35 openelec user.info kernel: [ 199.301902] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Code: Select all
Sep 21 12:07:43 openelec user.info kernel: [ 210.121636] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:46 openelec user.info kernel: [ 218.771782] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:46 openelec user.info kernel: [ 221.691677] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:07:46 openelec user.err kernel: [ 221.865701] mmc0: final write to SD card still running
Sep 21 12:07:56 openelec user.info kernel: [ 222.801799] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:07:56 openelec user.err kernel: [ 231.890917] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:07:56 openelec user.err kernel: [ 231.892136] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:07:57 openelec user.info kernel: [ 232.251759] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:08:35 openelec user.info kernel: [ 232.621758] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:08:47 openelec user.info kernel: [ 270.281782] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:08:48 openelec user.info kernel: [ 282.883053] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:08:54 openelec user.info kernel: [ 283.242634] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:08:57 openelec user.info kernel: [ 289.431744] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:08:57 openelec user.info kernel: [ 292.232046] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:08:57 openelec user.err kernel: [ 292.408994] mmc0: final write to SD card still running
Sep 21 12:09:07 openelec user.info kernel: [ 293.331889] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:09:07 openelec user.err kernel: [ 302.410947] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:09:07 openelec user.err kernel: [ 302.412144] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:09:12 openelec user.info kernel: [ 304.171827] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:09:12 openelec user.err kernel: [ 307.669055] mmc0: final write to SD card still running
Sep 21 12:09:22 openelec user.info kernel: [ 315.711848] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:09:22 openelec user.err kernel: [ 317.690910] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:09:22 openelec user.err kernel: [ 317.692220] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:09:29 openelec user.info kernel: [ 318.593416] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:09:29 openelec user.err kernel: [ 324.000582] mmc0: final write to SD card still running
Sep 21 12:09:33 openelec user.info kernel: [ 326.901927] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:09:33 openelec user.info kernel: [ 327.981717] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:09:39 openelec user.info kernel: [ 328.701873] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:09:39 openelec user.err kernel: [ 334.010996] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:09:39 openelec user.err kernel: [ 334.012791] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:09:41 openelec user.info kernel: [ 335.572726] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:09:43 openelec user.info kernel: [ 335.961816] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:09:53 openelec user.info kernel: [ 338.141757] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:09:53 openelec user.err kernel: [ 348.659019] mmc0: final write to SD card still running
Sep 21 12:09:59 openelec user.info kernel: [ 349.011796] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:10:00 openelec user.info kernel: [ 354.771714] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:10:03 openelec user.info kernel: [ 355.851734] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:10:03 openelec user.err kernel: [ 358.670955] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:10:03 openelec user.err kernel: [ 358.672275] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:10:13 openelec user.info kernel: [ 359.111803] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:10:13 openelec user.err kernel: [ 368.866892] mmc0: final write to SD card still running
Sep 21 12:10:23 openelec user.err kernel: [ 378.890940] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:10:23 openelec user.err kernel: [ 378.892044] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:10:31 openelec user.err kernel: [ 386.526991] mmc0: final write to SD card still running
Sep 21 12:10:41 openelec user.err kernel: [ 396.530925] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:10:41 openelec user.err kernel: [ 396.531053] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:10:42 openelec user.info kernel: [ 396.601831] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:10:46 openelec user.info kernel: [ 397.322039] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:10:46 openelec user.err kernel: [ 401.607456] mmc0: final write to SD card still running
Sep 21 12:10:56 openelec user.err kernel: [ 411.610910] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:10:56 openelec user.err kernel: [ 411.611924] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:11:03 openelec user.err kernel: [ 418.447052] mmc0: final write to SD card still running
Sep 21 12:11:13 openelec user.info kernel: [ 421.821819] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:11:13 openelec user.err kernel: [ 428.450932] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:11:13 openelec user.err kernel: [ 428.452107] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:11:15 openelec user.info kernel: [ 430.111923] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:11:15 openelec user.err kernel: [ 430.771672] mmc0: final write to SD card still running
Sep 21 12:11:25 openelec user.info kernel: [ 435.171805] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:11:25 openelec user.err kernel: [ 440.790922] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:11:25 openelec user.err kernel: [ 440.792120] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:11:42 openelec user.info kernel: [ 441.301698] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:11:42 openelec user.err kernel: [ 457.317148] mmc0: final write to SD card still running
Sep 21 12:11:52 openelec user.info kernel: [ 459.331890] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:11:52 openelec user.err kernel: [ 467.330913] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:11:52 openelec user.err kernel: [ 467.332166] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:12:14 openelec user.info kernel: [ 468.351728] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:12:14 openelec user.err kernel: [ 489.069581] mmc0: final write to SD card still running
Sep 21 12:12:24 openelec user.info kernel: [ 495.711874] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:12:24 openelec user.err kernel: [ 499.090924] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:12:24 openelec user.err kernel: [ 499.092107] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:12:37 openelec user.info kernel: [ 500.031636] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:12:37 openelec user.err kernel: [ 512.227804] mmc0: final write to SD card still running
Sep 21 12:12:47 openelec user.info kernel: [ 519.131846] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:12:47 openelec user.err kernel: [ 522.250950] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:12:47 openelec user.err kernel: [ 522.252217] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:13:07 openelec user.info kernel: [ 522.731716] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:13:07 openelec user.err kernel: [ 542.331482] mmc0: final write to SD card still running
Sep 21 12:13:17 openelec user.info kernel: [ 544.721840] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:13:17 openelec user.err kernel: [ 552.350946] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:13:17 openelec user.err kernel: [ 552.352182] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:13:18 openelec user.info kernel: [ 553.021718] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Sep 21 12:13:18 openelec user.err kernel: [ 553.437140] mmc0: final write to SD card still running
Sep 21 12:13:28 openelec user.info kernel: [ 561.741846] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)
Sep 21 12:13:28 openelec user.err kernel: [ 563.450917] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 21 12:13:28 openelec user.err kernel: [ 563.451109] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 21 12:13:30 openelec user.info kernel: [ 565.352333] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000)
Code: Select all
root ~ # pwd
/storage
root ~ # ls -la
Segmentation fault
Re: Updating to the 2012-09-18-wheezy-raspbian image
Well, I for my part decided to start from scratch with a clean image.lx-s wrote:I am encountering the exact same problem, do you or anyone else have a solution to this?aotto2012 wrote:
[...]
How can I fix this apart from installing the image from scratch?
Thanks in advance for your help!
Re: Updating to the 2012-09-18-wheezy-raspbian image
I've updated my firmware to the latest version, selected the Turbo mode (1000Mhz) and it's awsome!!!
The whole system seems to be a lot more usable and responsive!
Some weeks ago, I built XBMC and ran it but it was too slow and sluggish for me. Now, it seems to be as responsive as my main media server (Xtreamer sidewinder) but a lot more beautiful.
To stress it a little, I rebuilt FFMPEG (i'm using it for a little project). The CPU temperature reached 53° max and I had no crash nor freeze. It built during more than 2 hours.
So, thanks a lot to the team for these improvements, it's awesome!
FYI, my pi has SAMSUNG memory.
The whole system seems to be a lot more usable and responsive!
Some weeks ago, I built XBMC and ran it but it was too slow and sluggish for me. Now, it seems to be as responsive as my main media server (Xtreamer sidewinder) but a lot more beautiful.
To stress it a little, I rebuilt FFMPEG (i'm using it for a little project). The CPU temperature reached 53° max and I had no crash nor freeze. It built during more than 2 hours.
So, thanks a lot to the team for these improvements, it's awesome!
FYI, my pi has SAMSUNG memory.
My web site : https://codingfield.com
Re: Updating to the 2012-09-18-wheezy-raspbian image
In your case updating the kernel needs to be done through the Berryboot GUI.Joe! wrote:After the update & upgrade, upon reboot I still see:
Linux raspberrypi 3.1.9-cutdown-aufs #23 PREEMPT Mon Aug 13 15:20:21 CEST 2012 armv61
- During boot press a key within 3 seconds.
- Select "operating systems installer" from the Berryboot text boot menu
- in the GUI: click "Add OS" and choose "yes" when prompted if you want to update firmware.
Re: Updating to the 2012-09-18-wheezy-raspbian image
I measure it using cpufreq-info (you have to install cpufrequtils to use that). It shows the minimum frequency, the maximum frequency and the current frequency and they're all set to 700 MHz. And I measured speed with this command: time echo "scale=2000; a(1)*4" | bc -l It took about 29 seconds on the default RasPi and about 20 with 900 MHz. Now it's taking ~28 sec. againdom wrote:How are you measuring the frequency? It only increases when CPU is busy.der-don wrote:But now I've encountered a problem. The first switch to the 900 MHz boost level worked (as shown in the video), then I tried 1 GHz, but the RasPi started with 700 MHz again. When I try to another level, it just doesn't work, the cpu frequency remains at 700 MHz. I'm selecting a speed, reboot and then the PI still runs at the same speed. Is it a bug or a feature?Or am I doing something wrong?
