Setting up the Realtek’s card reader driver for Linux (Gentoo)

First time as I looked at my build-in into my laptop card reader to configure sdcard for the raspberry pi, it turned out that it was not working out of the box. Okey. It was not really a surprise to me. It was a RTS5229 PCI Express Card Reader:

# lspci -vvnn
09:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader [10ec:5229] (rev 01)
        Subsystem: Toshiba America Info Systems Device [1179:ff1e]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at d9400000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [140 v1] Device Serial Number 00-00-00-01-00-4c-e0-00
        Kernel driver in use: rts5229
        Kernel modules: rts5229

Next step is towards a working setup configuration is to make sure that the kernel options are properly set:

Device Drivers  --->
<M> MMC/SD/SDIO card support  --->
[*]   MMC debugging
<M>   MMC block device driver
(8)     Number of minors per block device
[*]     Use bounce buffer for simple hosts
<M>   Secure Digital Host Controller Interface support
<M>   SDHCI support on PCI bus

Moreover an additional driver should also be emerged sys-block/rts5229.

# emerge -a1v rts5229

If you have a RTS5209 card reader, then install sys-block/rts_pstor

That’s all, have fun!

Python dependency conflict with gnome-music-3.10

If it happens to you that you hit the following dependency conflict with different python versions involved, like:

 # emerge -a1v gnome-music

These are the packages that would be merged, in order:

Calculating dependencies -

!!! Problem resolving dependencies for media-sound/gnome-music
... done!

!!! The ebuild selected to satisfy "gnome-music" has unmet requirements.
- media-sound/gnome-music-3.10.1::gentoo USE="" PYTHON_SINGLE_TARGET="-python3_2 -python3_3" PYTHON_TARGETS="python3_3 -python3_2"

  The following REQUIRED_USE flag constraints are unsatisfied:
    exactly-one-of ( python_single_target_python3_2 python_single_target_python3_3 )

  The above constraints are a subset of the following complete expression:
    python_single_target_python3_2? ( python_targets_python3_2 ) python_single_target_python3_3? ( python_targets_python3_3 ) exactly-one-of ( python_single_target_python3_2 python_single_target_python3_3 )

while using the default python configuration:

$ emerge --info
Portage 2.2.7 (default/linux/amd64/13.0/desktop, gcc-4.8.2, glibc-2.17, 3.10.7-gentoo x86_64)
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3"

then this conflict can be temporarily resolved by adding a python_single_target_python3_3 USE flag to the corresponding ebuild:

$ cat /etc/portage/package.use/gnome-3.10
media-sound/gnome-music python_single_target_python3_3

Dual graphic card configuration on Gentoo

Recently, I was experimenting with OpenGL 3.3 support on my intel GPU within the newly released mesa 10.0.2.

Vendor: ........... Intel Open Source Technology Center
Renderer: ......... Mesa DRI Intel(R) Ivybridge Mobile 
Version: .......... 3.3 (Core Profile) Mesa 10.0.2
GLSL version: ..... 3.30

Sadly, it turned out, that the rotating cube made of triangles I was playing with was not drawn correctly as you can observe on this video. It took me a lot of time to realize, that it could be not just an oversight from my side but as well an undiscovered yet issue in the driver which I was trying out. It was about time to recall that my laptop has a hybrid video card. So, I started to think about an opportunity to configure it as well, to be able to test my sample code on the second video card I have. And I did.

Vendor: ........... NVIDIA Corporation
Renderer: ......... GeForce GT 640M/PCIe/SSE2
Version: .......... 3.3.0 NVIDIA 331.38
GLSL version: ..... 3.30 NVIDIA via Cg compiler

Luckily for me, at the end if this story my sample code was running fine, all issues I have observed with the intel mesa driver went away. It does not for sure mean, that my code is written correctly, but at least it’s a good indication, that it could be the case.

So, if you have a hybrid video card, like I do, there is a good and well supported on Gentoo project named Bumblebee which allows you to launch any application using the mighty secondary video card, in my case it’s GeForce GT 640M/PCIe/SSE2. I decided to go with a proprietary nvidia-driver, and therefore added it to my video card’s list side by side with intel:

# cat /etc/portage/make.conf
VIDEO_CARDS="intel nvidia" 

Updated my system afterwards and finally emerged bumblebee.

# emerge -a1v bumblebee

Make sure that you add yourself to the bumblebee group:

# gpasswd -a <user> bumblebee

As I have mentioned earlier bumblebee is well supported on Gentoo, so nothing else were required. The default configuration this ebuild provide is quite good as well.

Afterwards you should be able to launch any application on the secondary video card you desire with:

$ optirun <your app>

If you hit an error while trying to launch it, similar to this one:

$ optirun glxgears -info
[ 2108.388910] [ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[ 2108.388931] [ERROR]Could not connect to bumblebee daemon - is it running?

then just make sure that you have started the bumblebeed service:

# systemctl start bumblebeed
# systemctl status bumblebeed
bumblebeed.service - Bumblebee C Daemon
   Loaded: loaded (/usr/lib64/systemd/system/bumblebeed.service; disabled)
   Active: active (running) since Fri 2014-01-24 15:13:05 CET; 4s ago
 Main PID: 1487 (bumblebeed)
   CGroup: /system.slice/bumblebeed.service
           └─1487 /usr/sbin/bumblebeed

Jan 24 15:13:05 pls systemd[1]: Starting Bumblebee C Daemon...
Jan 24 15:13:05 pls systemd[1]: Started Bumblebee C Daemon.
Jan 24 15:13:05 pls bumblebeed[1487]: [ 2264.079511] [INFO]/usr/sbin/bumblebeed 3.2.1 started

Quickly applying patches on Gentoo

Sometimes, it’s necessary to apply a patch for a given package and there is no time and no desire to fork an ebuild to a custom overlay. Luckily Gentoo provides an easy way to so. All you need to do is to place a patch into the directory /etc/portage/patches/[category]/[ebuild’s name]/new-fix.patch. Sadly, not all ebuilds in the portage tree has a build-in support for this feature and to be on the safe side you can put the following hook into the portage’s bashrc file:

# cat /etc/portage/bashrc 
post_src_prepare() {
    if type epatch_user &> /dev/null ; then

Reference: Gentoo wiki

Enabling multilib abi_x86_32 support on the stable Gentoo system

Currently the abi_x86_32 use flag is masked on the stable Gentoo system. Therefore turning the 32 option in the ABI_X86 variable, will not bring you further:

# cat /etc/portage/make.conf
ABI_X86="32 64"

and as a result the line

# emerge --ask --verbose --newuse --update --deep world

will show you an endless number of conflicts, which can not be directly resolved by portage. If you never the less wish to enable the 32 bit library support on your system, especially to make your 32 bit applications running well under wine, you should force the abi_x86_32 desired use flag. One of the possible solutions to achieve this would be:

# cat /etc/portage/profile/use.mask 

Moreover, more additional packages are required to have a full multilib featured support. Many of them has not been marked as stable yet. An up to date list of this packages at the moment of writing can be found here:

# cat /etc/portage/package.keywords/multilib


If emerge still has troubles to resolve all conflict, try to temporarily remove all emul-linux-x86-* ebuilds first, and all conflict should go away. Enjoy Gentoo!!!

New safe CFLAGS optimization for the Intel I7 CPUs with GCC up to 4.7

If you have a new Intel core Core i3/i5/i7 CPUs, like for example:

$ grep -m1 -A3 "vendor_id" /proc/cpuinfo
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz

then the recent GCC version, starting with the version 4.7 brings a new support for optimization flags.

 $ gcc-config -l
 [1] x86_64-pc-linux-gnu-4.6.3
 [2] x86_64-pc-linux-gnu-4.7.2 *

For the IvyBridge chipset

  $ dmesg | grep Ivy
[    0.179101] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, Intel PMU driver.
[    0.922097] pci 0000:00:00.0: Intel Ivybridge Chipset

a new march option can be used:

File: /etc/portage/make.conf
CFLAGS="-march=core-avx-i -O2 -pipe"

More Information can be found on Gentoo wiki and on the Intel pages.

Getting Stack Traces and Debugging Information on Gentoo

If you want to extract a useful debugging information from a crashing application do not try mistakenly to enable the “debug” USE flag in the corresponding ebuild. The “debug” USE flag is used for other purposes [1]. The proper way to do so, is mostly to enable the “-ggdb” compile flag and rebuild the application. In the case of “evince” the command line would be:

# CFLAGS="-march=native -pipe -O2 -ggdb" \
FEATURES="${FEATURES} splitdebug" emerge -1av evince

Luckily, there is no need to keep this in mind, because portage provides a possibility of configuration storing [2,3]. So the debugging configuration can be created once and used for all later purposes. To make use of it, create an “env” directory

# mkdir -p /etc/portage/env/

and put the above introduced debug setup in the file of your taste, like a “debug.conf”:

# cat /etc/portage/env/debug.conf
CFLAGS="-march=native -pipe -O2 -ggdb"
FEATURES="${FEATURES} splitdebug"

For now you can place all packages you would like to debug in the “package.env” file, using the following already similar to you syntax:

# cat /etc/portage/package.env
app-text/evince debug.conf
dev-libs/glib debug.conf
dev-libs/gtk+ debug.conf
# >gnome-base/nautilus-3.8.1 debug.conf

Rebuild the desired packages and you are ready for debugging:

# emerge -a1v evince glib gtk+

Obtaining stack traces is a straightforward process from this point, which mainly consists of issuing the following commands in order within gdb [1,4]:

$ gdb evince
GNU gdb (Gentoo 7.5.1 p2) 7.5.1

(gdb) run

(gdb) set logging file backtrace.log
(gdb) set logging on
Copying output to backtrace.log.

(gdb) thread apply all bt full

(gdb) set logging off
Done logging to backtrace.log.
(gdb) quit

Further resources:

  1. How to get meaningful backtraces in Gentoo
  2. Overriding environment variables per package
  3. /etc/portage/env
  4. Getting Traces in GNOME