User:Tbird20d

From RTwiki
Jump to: navigation, search

This is Tim Bird's personal page on the linux RT wiki.

You can contact me at: tim (dot) bird (at) am (dot) sony (dot) com

Contents

Info I'm collecting

How to debug clockevents, HRT, and RT-preempt

Thomas said:

The output of /sys/devices/system/clocksource/clocksource0/available_clocksource and a full boot log are more interesting [to debug why a machine didn't switch into high resolution mode]


On my MIPS system (tx4927 Toshiba board):

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
MIPS jiffies
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
MIPS

I didn't see anything interesting in dmesg output.


On an OSK system on which I had HRT running, I see the following:

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
mpu_timer2 32k_counter jiffies
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
mpu_timer2

Here are some interesting lines from dmesg:

Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000
Clocking rate (xtal/DPLL1/MPU): 12.0/192.0/192.0 MHz
...
Time: mpu_timer2 clocksource has been installed.
Switched to high resolution mode on CPU 0

How to cross-compile the IBM tests

I tried this:

$ CC=${CROSS_COMPILE}gcc ./configure --host=mips-linux


Notes on MIPS preempt-rt work

MIPS lack of instrumentation for debugging

John Cooper wrote about this at: http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html

The basic problem is that the MIPS ABI doesn't support __builtin_return_address(), which makes stack traces hard (for latency trace).

Personal tools