Firmware/kernel incompatibility?

[NickT]

I've rebuilt the kernel a couple of times now to include the latest updates and it's all gone well previously. I started off with a 'git clone' and then used 'git pull' to get the latest sources subsequently. I've always followed the guide at http://elinux.org/Rpi_kernel_compilation#Ubuntu_Linux and it's been OK.

I've rebuilt the kernel today and noting the remarks about having to have matching firmware for this kernel I did an rpi-update, skipping the kernel, so I've got new start.elfs and bootcode.bin. Now when the Pi boots it takes much longer than before and in dmesg o/p I have :

Code: Select all

mmc0: final write to SD card still running
eth0: no IPv6 routers present
mmc0: Timeout waiting for hardware interrupt - cmd12.
mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

Also the command sudo hdparm -t /dev/mmcblk0 gives me:
Timing buffered disk reads: 60 MB in 3.05 seconds = 19.68 MB/sec

I suspect I may have an incompatibility in the init_emmc_clock=xxxx and that it's trying to write to my class 4 card too quickly and failing sometimes

How can I check and hopefully put it right?

[dom]

See this commit messge
https://github.com/raspberrypi/firmware ... 662430ea5f

So, you have latest GPU firmware? Can you confirm that with
/opt/vc/bin/vcgencmd version

Did you merge in newest code to your kernel tree?

I guess trying with official kernel.img to see if that aso has the same result would be useful.

[NickT]

Yes, I saw the message, hence my remark about the init_emmc_clock.
The command you mentioned gives me

Code: Select all

pi@itsmypi:~$ /opt/vc/bin/vcgencmd version
Jun 13 2012 11:55:25
Copyright (c) 2012 Broadcom
version 319515 (release)
 Is that OK?

I got all the elfs and bins from git just now on to my Windows m/c and did a fc /B in a DOS box.
All the elfs were the same except for start.elf itself. I put the giit one on the Pi and got the same result. The kernel.img IS different but that's not surprising as I cross compiled it on my Ubuntu machine with a 4.6 gcc. I'll try the actual kernel.img from git in a minute or two and get back to you

[NickT]

As far as I know I merged in the kernel code. I'd done some builds before and they were OK. After I had seen the commit in the Linux repository 'Merge pull request #36 from grigorig/sdhci-perf-cleanup ', I did a git pull from my Linux folder on the build machine and rebuilt the kernel.

My kernel.img (copied over from Image) was only 4,113,924 bytes, the cutdown one in git is 4,195,844 bytes. I copied the kernel_cutdown.img from git to kernel.img on my Pi and rebooted. I get the same slow boot and errors as in my first post. I've also put a line in config.txt setting the clock to 50000000.

Have I made any errors? (I'm a bit puzzled about the size discrepancy even allowing for different compiler versions) I've only made one small custom change to the kernel, which was to put the active state for the OK LED back to 0. I only did this to see that my changes were showing up on the device

[NickT]

I might be asking a dim question here, as I know next to nothing about SD cards. The card was a class 4, which according to Wiki has a max read speed of 4MB/s. Why was the speed test I ran showing that it was reading at 19MB/s? Is the driver supposed to auto-detect the card type and adjust accordingly? If so, it's not working!

[asb]

I might be asking a dim question here, as I know next to nothing about SD cards. The card was a class 4, which according to Wiki has a max read speed of 4MB/s. Why was the speed test I ran showing that it was reading at 19MB/s? Is the driver supposed to auto-detect the card type and adjust accordingly? If so, it's not working!

The 'class' is actually the sustained write speed.

[NickT]

UPDATE:

I went back to a previously stored image which had none of my code or builds on it, it was all stock plus previous rpi-updates. I reflashed my SD card with this then I performed an rpi-update, including the firmware. I rebooted. The dmesg contains the same sort of errors relating to 'SD card writes still running'. Here's a screen dump taken just now

Code: Select all

[   40.681592] mmc0: final write to SD card still running
[   50.676379] mmc0: Timeout waiting for hardware interrupt - cmd12.
[   50.677566] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[   51.204030] mmc0: final write to SD card still running
[   61.196374] mmc0: Timeout waiting for hardware interrupt - cmd12.
[   61.197593] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

I think there is a problem with the latest timing changes in the mmc core and not my kernel build

Incidentally the SD card I was using last night is now dead, in that although I can reflash it with a previous image, it won't boot ( power led and that's all). My other card will take the images and boot OK. The dead card was a full price from Sainsburys 4GB, class4. I'm not going to do any more investigation on this in case the other card goes the same way. I shall reflash it with the image I saved prior to this latest commit.

[dom]

@NickT
There has been a fix to firmware for the cmd12 timeout problem you saw. You will get the fix from Hexxeh's rpi-update.

[nommo]

I am getting the same errors, I haven't done anything fancy (like writing my own code or testing the latest commits) as I'm still getting my head around linux, but I did recently start getting these errors after an rpi-update. I was playing with tmux last night (what a revelation!) when it started behaving strangely - so I rebooted. That's when I started seeing these errors.

Code: Select all

pi@raspberrypi:~$ /opt/vc/bin/vcgencmd version
Jun 13 2012 11:52:26
Copyright (c) 2012 Broadcom
version 319513 (release)

Edit: Ah thanks Dom! I'll also try another update...

[NickT]

@dom
Thank you for the update. I did see the code go into github late last night. I can confirm that both an rpi-updated kernel and one built from a git pull are free of the previously reported errors. I did a brief speed test as described before and was surprised to see my class 4 card reporting ~19MB/s though.

[davka003]

Hi
I can confirm the problem still exist after the June 17 update.

Code: Select all

[ 1424.218607] mmc0: final write to SD card still running
[ 1434.086510] mmc0: Timeout waiting for hardware interrupt - cmd12.
[ 1434.086676] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[ 1715.229574] mmc0: final write to SD card still running
[ 1725.106994] mmc0: Timeout waiting for hardware interrupt - cmd12.
[ 1725.107161] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[ 1805.239793] mmc0: final write to SD card still running
[ 1815.102548] mmc0: Timeout waiting for hardware interrupt - cmd12.
[ 1815.103724] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
pi@raspberrypi:~$ sudo /opt/vc/bin/vcgencmd version
Jun 17 2012 13:30:15
Copyright (c) 2012 Broadcom
version 320121 (release)

I am still running the "old" debian release “squeeze" but been using Hexxeh's rpi-update tool.

My feeling is that the problem got much more serious after installing mysql, rabbitmq and celery, but that is probably just because I have more activity on the board/sd-card now.

B.R.
David

[dom]

Hi
I can confirm the problem still exist after the June 17 update.

So did any earlier firmware work correctly with this card?

I think you should raise this in this thread:
http://www.raspberrypi.org/phpBB3/viewt ... &start=175

where lb may have suggesions.

[clausmuus]

Hi,

does anybody has a solution for this?
It's a real problem since the system seems to hang every time I get this message, and this is at minimum one times per minute
I tested with the latest version of the kernel and start.elf of the Jul 10.
Does anybody know witch is the latest Version (date) of the start.elf that has not this problem (if it's really a problem of the firmware)?

Claus

[clausmuus]

With the new firmware it seems, that I got not so much error messages but under heavy load (e.g. on boot up) I still got this error messages.

Claus