RT Patch set, SystemTap, tcp test fails

Hi I'm trying to get systemtap to work with Ingo Molnar's RT patch set and have run into a few problems. My test setup is a dual Xeon IBM intellistation with fc6 and 2.6.18-rt7 #1 SMP PREEMPT.

Running the last systemtap snapshot I get the results

                === systemtap Summary ===

# of expected passes            147
# of unexpected failures        4
# of expected failures          116
# of unknown successes          2
# of known failures             3
# of untested testcases         74

The the tcp test fails because the symbol HRTIMER_REL cannot be found. detail for the tcp tests is.

/home/sperryd/kernels/systap18rt7/src/testsuite/buildok/tcp_test.stp
-vvvv

probe_1509 probe_1511 probe_1512 enter_kprobe_probe
enter_kretprobe_probe enter_hrtimer_probe systemtap_module_init /tmp/stapc3sTb9/stap_638ce45d23c34f17540fb6c3ee1929a7_3720.c: In function 'systemtap_module_init':
/tmp/stapc3sTb9/stap_638ce45d23c34f17540fb6c3ee1929a7_3720.c:1544:
error: 'HRTIMER_REL' undeclared (first use in this function) /tmp/stapc3sTb9/stap_638ce45d23c34f17540fb6c3ee1929a7_3720.c:1544:
error: (Each undeclared identifier is reported only once /tmp/stapc3sTb9/stap_638ce45d23c34f17540fb6c3ee1929a7_3720.c:1544:
error: for each function it appears in.)
cc1: warnings being treated as errors /tmp/stapc3sTb9/stap_638ce45d23c34f17540fb6c3ee1929a7_3720.c:1545:
warning: assignment from incompatible pointer type
systemtap_module_exit probe_start probe_exit __check_send_bytes
__check_recv_bytes __check_ports __check_rtos __check_state __check_mss __check_ssthresh __check_cwnd

Is there a way to make systemtap RT aware?

Thanks
Dave

According to mingo's patch set, HRTIMER_REL and HRTIMER_ABS were simply renamed to HRTIMER_MODE_REL and HRTIMER_MODE_ABS. Since these are enums instead of macros, a little #ifndef/#define hack would not work. Unless the RT patches identify themselves at compile time, it may be tricky to generate code that works with both base and patched kernel.

- FChE

Thanks for the response. Just to get a workaround I changed tapsets.cxx and cleared up that particular error for my system.

@@ -4332,13 +4332,13 @@ hrtimer_derived_probe_group::emit_module
 
   s.op->newline() << "for (i=0; i<" << probes.size() << "; i++) {";
   s.op->newline(1) << "struct stap_hrtimer_probe* stp = &

stap_hrtimer_probes [i];";
- s.op->newline() << "hrtimer_init (& stp->hrtimer, CLOCK_MONOTONIC, HRTIMER_REL);";
- s.op->newline() << "stp->hrtimer.function = & enter_hrtimer_probe;";
+ s.op->newline() << "hrtimer_init (& stp->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);";
+ s.op->newline() << "stp->hrtimer.function = (void *)(& enter_hrtimer_probe);";
// There is no hrtimer field to identify *this* (i-th) probe handler // callback. So instead we'll deduce it at entry time. s.op->newline() << "(void) hrtimer_start (& stp->hrtimer, "; emit_interval (s.op);
- s.op->line() << ", HRTIMER_REL);";
+ s.op->line() << ", HRTIMER_MODE_REL);";
// Note: no partial failure rollback is needed: hrtimer_start only // "fails" if the timer was already active, which cannot be. s.op->newline(-1) << "}"; // for loop

Hopefully I didn't break something else

Dave

The real-time patch replaces the enumeration constants:

enum hrtimer_mode {

-       HRTIMER_ABS,    /* Time value is absolute */
-       HRTIMER_REL,    /* Time value is relative to now */
+       HRTIMER_MODE_ABS,       /* Time value is absolute */
+       HRTIMER_MODE_REL,       /* Time value is relative to now */

};

It is possible to achieve backwards compatibility in enumerations by simply declaring the deprecated names to have the values assigned to the new names:

enum hrtimer_mode {
HRTIMER_MODE_ABS, /* Time value is absolute */
HRTIMER_ABS = HRTIMER_MODE_ABS, /* backwards compatibility */
HRTIMER_MODE_REL, /* Time value is relative to now */
HRTIMER_REL = HRTIMER_MODE_REL, /* backwards compatibility */
};

Regards,

Bill Rugolsky