From RTwiki

The 'make config' screenshots are illegible for me, can anyone else read them?

_________________________________________________

Hi,

No, I can't read them either. Perhaps I need higher resoloution and subpixel hinting?

This is a truly wonderful project, many thanks...

Although some systems may have a bzcat2 alias for bzcat, on my system the man page for bzip2 begins:

SYNOPSIS

      bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ...  ]
      bunzip2 [ -fkvsVL ] [ filenames ...  ]
      bzcat [ -s ] [ filenames ...  ]
      bzip2recover filenam

Note that it has bzcat not bzcat2.

I apologize if editing bzcat2->bzcat on the installation page is poor protocol--you could always change it back :-) It gave me a moment's panic when I couldn't find bzcat2 to patch the kernel. But I feel much better now <VBG>

--Lawrence

rt_down_timeout bug

at time of writing the rt_down_timeout() function is buggy.

this seems to launch a timer with no fonction to call.

unfortunately this will generate an exception when timeout is reached  :

BUG: unable to handle kernel NULL pointer dereference at 00000000 
IP: [<00000000>] 
*pde = 00000000 
Oops: 0000 [#1] PREEMPT 
Dumping ftrace buffer: 
   (ftrace buffer empty) 
 

Pid: 5, comm: sirq-timer/0 Tainted: P          (2.6.26.5-rt9-ipipe #2) 
EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0 
EIP is at 0x0 
EAX: dc11df0c EBX: 00000000 ECX: 00000001 EDX: 00000000 
ESI: dc11df0c EDI: c0498e20 EBP: ddc29f58 ESP: ddc29f40 
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 preempt:00000001 
Process sirq-timer/0 (pid: 5, ti=ddc29000 task=ddc44d80 task.ti=ddc29000) 
Stack: c0133e3a 00000000 c0498ea4 00000202 c050af80 fffffffd ddc29f6c c0134a38 
       c050af80 ddc29f6c 00000202 ddc29fa0 c0126452 00000001 00000002 c050aab0 
       ddc29f88 c013da9b ddc29fa0 00000046 00000002 00000002 c050aab0 fffffffd 
Call Trace: 
 [<c0133e3a>] ? run_hrtimer_pending+0x5a/0x110 
 [<c0134a38>] ? hrtimer_run_pending+0x48/0xe0 
 [<c0126452>] ? run_timer_softirq+0x82/0x2c0 
 [<c013da9b>] ? trace_hardirqs_on+0xb/0x10 
 [<c012298d>] ? ksoftirqd+0x10d/0x230 
 [<c0122880>] ? ksoftirqd+0x0/0x230 
 [<c0130716>] ? kthread+0x46/0x80 
 [<c01306d0>] ? kthread+0x0/0x80 
 [<c0103cf3>] ? kernel_thread_helper+0x7/0x10

the modified run_hrtimer_pending function() modified bypass the problem but is NOT a solution

static void run_hrtimer_pending(struct hrtimer_cpu_base *cpu_base)
{
spin_lock_irq(&cpu_base->lock);

while (!list_empty(&cpu_base->cb_pending)) {
enum hrtimer_restart (*fn)(struct hrtimer *);
struct hrtimer *timer;
int restart;

timer = list_entry(cpu_base->cb_pending.next,
struct hrtimer, cb_entry);

debug_hrtimer_deactivate(timer);
timer_stats_account_hrtimer(timer);

+ if (timer)
     fn = timer->function; 
__remove_hrtimer(timer, timer->base, HRTIMER_STATE_CALLBACK, 0);
spin_unlock_irq(&cpu_base->lock);

+ if (fn != NULL)
  restart = fn(timer);

mailto:sancelot@free.fr Sancelot 08:44, 28 October 2008 (UTC)

rt preempt support

linux rt preempt seems being very nice opportunity for the embedded and realtime community .

however , lacks at this time of support , although the linux kernel mailing list should be used, this is a good initiative, but too much involved in the linux development and not the realtime issues .

do not expect have an answer ... mailto:sancelot@free.fr 08:42, 28 October 2008 (UTC)