I'm using the 2.2.18 kernel that came with the RTL 3 distribution.
I've tested my rt code using the above-linux memory trick and I have the
exact problem. If I allow the function to write past a buffer boundary,
the computer goes into never-never land. If I dont, then everything runs
fine.
I was actually afraid of this since the above memory is mapped into kernel
space with ioremap and it may be chopping it up into pages.
Is there anything wrong with the following?
unsigned long pmembase;
volatile void *vmembase;
struct MyBufferHdr *buffers[NBUFS+2];
...
pmembase = linux_physmem_max * MEGABYTE;
vmembase = ioremap(pmembase, ABUF_SIZE * (NBUFS + 2));
for (i = 0; i < NBUFS+2; ++i)
buffers[i] = (struct MyBufferHdr*>((unsigned long)vmembase
+ (i * ABUF_SIZE));
Maybe I messed up the installation of the RTL 3 installation. I cannot work
out of the installed directory /usr/rtlinux. Instead, I'm working out of
the /usr/src/rtlinux directory, ie, I load my modules from scripts/insrtl,
use the includes from there, etc.
I'd appreciate some resolution of this problem or hints and suggestions on
further investigation to pin down the real problem.
If I really cannot page, then I will be forced to rearchitect my code. The
reason why I let the writing function overrun a buffer boundary is that the
rt code I'm writing is really a framework that calls a user-written writing
function and I'd like to decouple the framework and the writing function as
much as possible.
Thanks! Ken
On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
> If you are using a Linux 2.4.x kernel, you must use the vmalloc
> patch.
>
> On Tue, Apr 10, 2001 at 03:59:50PM -0500, Ken Teh wrote:
> > It appears that I cannot page when running my rt code. RTLinux is version
> > 3.0
> >
> > I have a statically defined buffer that is partitioned into n+2 buffers, each
> > 2048 bytes long and a function that fills these buffers with multiple
> > blocks of "event" data. The function writes arbitrary length event data and
> > I allow the function to overrun a buffer boundary. The calling function
> > actually catches the overrun and translates (shifts) the "last" event into
> > the next buffer so that the completed buffer does not contain partial event
> > data.
> >
> > The system does an oops when the function overflows from buffer 1 (first
> > buffer is buffer 0) into buffer 2. At times it's worse -- it resets the
> > computer and goes into the reboot cycle. If I fix the function so it never
> > overruns a buffer boundary, then the code runs without any problems.
> >
> > The n buffers are actually made into a circular buffer queue. The n+1
> > buffer is used for the overflow of buffer n, and the n+2 buffer is the
> > temporary buffer which I use to translate an event data block that has
> > overrun a buffer boundary. I've checked that with my modified function
> > (that does not overrun a buffer boundary), that the buffers "circulate"
> > without any problems.
> >
> > My inference is that my logically contiguous buffer that is partitioned into
> > n+2 buffers is not really physically contiguous and that when my function
> > overflows buffer 1, ie, crosses a page boundary, the system does a hard
> > crash. I have the same behaviour with the mbuff device. The function is
> > called by a thread that is dispatched by an interrupt handler.
> >
> > Can anyone shed light on this?
> >
> > The oops message repeats, but I don't know how to read an oops and I've seen
> > 2 varieties of oops messages - one says kernel cannot deference NULL virtual
> > pointer, process is init, the second variety says something about trying to
> > kill an interrupt handler, aiee killing idle task. I'm not sure I believe
> > either one.
> >
> > Ken
> >
> > -- [rtl] ---
> > To unsubscribe:
> > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> > --
> > For more information on Real-Time Linux see:
> > http://www.rtlinux.org/rtlinux/
>
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
