Differences between stock (3.2.27+) and git (3.2.27) kernel

Hello everyone,

Recently I got my Pi. Downloaded the image from Foundation's website, everything worked. After a while, I needed to compile some modules (drivers), so I downloaded the kernel source from https://github.com/raspberrypi/linux.git.
In that moment I thought the kernel I had installed (3.2.27+) is the same as source (3.2.27). It wasn't.
The kernel compiled from source successfully, works in general, but has some issues, compared to stock one:

• self-compiled has lower BogoMIPS (464.48 compared to 700). But the CPU performance remains the same (tested with linpack from http://elinux.org/RPi_Performance) on both kernels... Is that an issue?
• Card I/O performance remains the same on both kernels.
• dmesg shows the following during boot:
  

  Code: Select all

  [   10.447359] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   10.896514] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
...
[   16.380310] mmc0: missed completion of cmd 18 DMA (512/512 [1]/[1]) - ignoring it
[   16.395985] mmc0: DMA IRQ 6 ignored - results were reset


  
  Why the card is remounted twice? And the entries missed completion are repeated about 20 times. This happens on every boot. Read elsewhere this behaviour may be due to overclocking, but my Pi is not overclocked... Apart from this entries everything works.
• When I created .config file from running 3.2.27+ configuration, make oldconfig asked me for the following:
  

  Code: Select all

  BCM2708 DMA helper (BCM2708_DMAER) [N/m/y/?] (NEW)


  
  I answered y. Now, I wanted to learn what this setting does, but didn't find anything. What this setting does?

I was just compiling the kernel myself and ran into the same issue and found your post here. I was wondering the exact same thing. I thought about it a bit and the DMA bit somehow sounded familiar. I googled and indeed, it stood for direct memory access. I am guessing this option gives the GPU direct memory access to the RAM, making it faster. Not sure though. Can someone confirm this?

DMA (Direct Memory Access) means that the processor doesn't have to address the device directly (which may be slow), but rather some memory space is "dedicated" for the hardware to be accessed directly, without the processor taking part in it. This is not limited to GPU, can be applied to any hardware, including memory card controller (which would be the case here, notice mmc0:).

From menuconfig for the 3.6.11 kernel

Code: Select all

CONFIG_BCM2708_DMAER:
Enable DMA helper for accelerating X composition

Symbol: BCM2708_DMAER [=n]
Type  : tristate                                             
Prompt: BCM2708 DMA helper                                     
Defined at arch/arm/mach-bcm2708/Kconfig:34                   
Depends on: ARCH_BCM2708 [=y] && MACH_BCM2708 [=y]
Location:                                             
     -> System Type                                                      │ 
       -> Broadcom BCM2708 Implementations                               │ 
         -> Broadcom BCM2708 Development Platform (MACH_BCM2708 [=y])


The Bogomips=464.48 doesn't look confined to 3.2.27+

Code: Select all

Linux tau 3.6.11+ #1 PREEMPT Mon Dec 24 16:44:34 UTC 2012 armv6l ARMv6-compatible processor rev 7 (v6l) BCM2708 GNU/Linux

Dec 19 2012 23:13:22
Copyright (c) 2012 Broadcom
version 359004 (release)


This is on both a version 1.1(0003) and a version 2(000f). Both run off external hard drives, would that make a difference?

Neither run Raspbian, so the bogomips thing seems neither a Raspbian or 3.2.27 specific issue.

by dom » Wed Sep 26, 2012 2:10 pm

milhouse wrote:Getting the same low 464.48 BogoMIPS too in the latest OpenELEC r12006:

Code: Select all
root ~ # vcgencmd version
Sep 25 2012 00:18:47
Copyright (c) 2012 Broadcom
version 339137 (release)

root ~ # uname -a
Linux rpi 3.2.30 #1 PREEMPT Wed Sep 26 04:14:37 BST 2012 armv6l GNU/Linux



My arm_freq is set to 1000.



I think that is harmless, as udelay no longer uses the value from BogoMips for determining how long to wait for.
However, it looks wrong, and so I've pushed out a fix.

Was this fix for the 464 bogomips issue? If so, how to enable it?

The Bogomips=464.48 doesn't look confined to 3.2.27+

3.2.27+ has BogoMIPS=697, 3.2.27 has BogoMIPS=464 - just to clarify.

This is on both a version 1.1(0003) and a version 2(000f). Both run off external hard drives, would that make a difference?

I've got rev. 2.0 (000f). Not sure, but external HDD should have no impact, as I have an external drive too.

Getting the same low 464.48 BogoMIPS too in the latest OpenELEC r12006:
[...]
Was this fix for the 464 bogomips issue? If so, how to enable it?

Yeah, where's the patch and what does it give?

Just compiled a 3.6.11 kernel. This one shows BogoMIPS=697.95. What's more interesting, after overclocking (to 800, later to 900 MHz), BogoMIPS remained the same...

I'm also an RPi newbie, and got to this topic via the link on the RPi Kernel Compilation page on eLinux.org. Looking in the git repository, rpi-3.2.27 is a branch, not a tag, so fetching it will give different code versions at different times, based on the changes in the branch. I didn't see any tags in the repository that would give a fixed version. I guess the git version is a later version than 3.2.27+ (based on the fact that the dma helper option is in git but not 3.2.27+), so I think using the git version is the best option - I image all the changes went in for a reason.

[dom]

Just compiled a 3.6.11 kernel. This one shows BogoMIPS=697.95. What's more interesting, after overclocking (to 800, later to 900 MHz), BogoMIPS remained the same...

Turbo only gets enabled from init, after bogomips has been calculated (bogomips only gets calculated once).
Add "initial_turbo=30" to config.txt to force turbo for first 30 seconds, and you will see the higher bogomips score.