Re: rt20 patch question

[Steven Rostedt]

>
> So to my problem. What I mean by "the machine stops" is just that all
> indications of the mouse, keyboard, and vidio stop. Then in a few
> seconds will usually continue. At first I only saw problems when using
> ethernet in the emulation. I would telnet into the emulation from the
> linux box and do the equivalent of cat'ing a very large file. The
> machine will always "stop" somewhere randomly along the display. Then
> maybe continue on or maybe not. So I thought I might have a problem with
> my ethernet module. Then I noticed similar things with the SCSI module
> when accessing legacy scsi devices from within the emulation. Somtimes
> the whole machine doesn't stop. It would appear that only somethings
> have stopped. Like one or more of my I/O threads??
>
> I can only say for sure that I do not have these "stops" when running
> any other kernel or when running the rt20 kernel in any of the
> non-complete preemption modes.
>
> The only change that had to be made to this app for it to run at all on
> the rt20 kernel was insuring that the RTOM irq thread was at a higher
> priority than the CPU process/thread. Otherwise no signals were received
> from the RTOM.
>

(Working way to late! need to go home)

Mark, could you do the following for me.  I would really like to see what
is being scheduled, and when.  Could you apply the following patch:

http://www.kihontech.com/logdev/logdev-2.6.16-rt20.patch

Then do a "make oldconfig"  and answer the following questions:

Enable hooks for logdev device (LOGDEV_HOOKS) [N/y/?] (NEW) y
 Enable logdev device (LOGDEV) [M/n/y/?] (NEW) y
   Number of pages to allocate for logdev device (LOGDEV_PAGES) [256] (NEW)
   Logdev Multiple CPU buffers (LOGDEV_MULTI_CPUS) [N/y/?] (NEW) n
  Default Logdev prints should be enabled on startup (LOGDEV_PRINT_ENABLED) [Y/n/?] (NEW) n
  Default Logdev printing of context switches on startup (LOGDEV_SWITCH_ENABLED) [N/y/?] (NEW) n

So basically hit yes for the first two, and use whatever for the number of
pages.  And no to the rest.

This is a kernel ring buffer. But one of the things it records nicely is
scheduling switches.  The size of the ring buffer is defined by
LOGDEV_PAGES, and the bigger that is the more memory it will use.

Then make and install this kernel.

Then download: http://www.kihontech.com/logdev/logdev_tools-0.3.1.tar.bz2

Untar it and compile it with:

make KERNDIR=<path_to_kernel_dir_with_logdev_patch>/include


And then copy logread onto the machine that's running the kernel.

Boot into that kernel, and on this machine do:

# echo 1 > /proc/logdev/switch

Run your tests, and just after you see the machine freeze, do a

# echo 0 > /proc/logdev/switch

right away, otherwise the buffer might over flow.  Obviously you can't do
it while the machine is frozen, but it should be ok to do it as soon as
the machine is back up running.  You could just have a terminal up with
the echo ready, and when the machine freezes, hit enter, and hopefully the
buffered interrupt will go off after the machine is unfrozen.

Then do the

# ./logread > log.out

and email me privately, a compressed version of that log.out. It will show
nicely the scheduling that has taken placed:

ie.

[  614.937438] CPU:0 (posix_cpu_timer:2) -->> (softirq-timer/0:4)
[  614.937443] CPU:0 (softirq-timer/0:4) -->> (swapper:0)
[  614.938434] CPU:0 (swapper:0) -->> (posix_cpu_timer:2)
[  614.938436] CPU:0 (posix_cpu_timer:2) -->> (softirq-timer/0:4)
[  614.938438] CPU:0 (softirq-timer/0:4) -->> (swapper:0)
[  614.938777] CPU:0 (swapper:0) -->> (IRQ 11:710)


So at least I can see what is running on which CPU.

Thanks,

-- Steve

PS. Someday I plan to use relayfs as a backend and clean it up to perhaps
get this into the kernel.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/