Page 6 of 10

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 6:41 pm
by Joe!
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

Posted: Thu Sep 20, 2012 6:58 pm
by dom
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?
That's not the default raspbian/wheezy kernel. Did you start from a different image?

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 7:09 pm
by Joe!
dom wrote:
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?
That's not the default raspbian/wheezy kernel. Did you start from a different 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.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 7:26 pm
by dom
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.
I believe you are using Berryboot. You might need to uninstall that first, or start with a clean image.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 8:11 pm
by williamhbell
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

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 8:16 pm
by tokyostormdrain
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:
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 :(
Make sure you execute this after update n upgrade,

Code: Select all

sudo apt-get install raspberrypi* raspi-config

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 10:56 pm
by forenbenutzer
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?

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 11:04 pm
by SiriusHardware
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.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 11:14 pm
by tokyostormdrain
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:
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 :(
Make sure you execute this after update n upgrade,

Code: Select all

sudo apt-get install raspberrypi* raspi-config

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Thu Sep 20, 2012 11:26 pm
by SiriusHardware
Ed Raket wrote:
dom wrote:
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
Is this from an updated older image, or a new intall?
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.
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? :?
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.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 1:28 am
by Bleugh
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”

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 6:12 am
by Ed Raket
SiriusHardware wrote:
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? :?
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.
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

Posted: Fri Sep 21, 2012 6:35 am
by milhouse
Ed Raket wrote: Then it would seem that the Pi itself scrambles the SD card when overclocked... interesting :?
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.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 7:13 am
by milhouse
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):

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
Transcend 8GB Class 10.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 8:25 am
by Ed Raket
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 :D

Maybe we should open a wiki section for "turbo mode compatible" SD card's?

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 8:57 am
by dom
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.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 9:13 am
by der-don
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?

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 9:40 am
by DRB666
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!

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 9:47 am
by dom
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?
How are you measuring the frequency? It only increases when CPU is busy.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 10:16 am
by wallarug
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?

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 11:20 am
by milhouse
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 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).

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)
It was then at this point that I selected Reboot from the GUI menu, and instead of rebooting the device OpenELEC simply restarted XBMC - within a few seconds the SD errors began to appear...

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)
The system is now unusable and the partition almost certainly corrupt, with even just "ls -la" producing a seg fault!

Code: Select all

root ~ # pwd
/storage
root ~ # ls -la
Segmentation fault
Will try to pin it down further.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 4:07 pm
by aotto2012
lx-s wrote:
aotto2012 wrote:
[...]

How can I fix this apart from installing the image from scratch?
I am encountering the exact same problem, do you or anyone else have a solution to this?

Thanks in advance for your help!
Well, I for my part decided to start from scratch with a clean image.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 4:19 pm
by JF002
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.

Re: Updating to the 2012-09-18-wheezy-raspbian image

Posted: Fri Sep 21, 2012 4:50 pm
by Max
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
In your case updating the kernel needs to be done through the Berryboot GUI.
  • 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

Posted: Fri Sep 21, 2012 9:42 pm
by der-don
dom wrote:
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?
How are you measuring the frequency? It only increases when CPU is busy.
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. again :(