Steve,
> Whatever you do, do not get into the habit of using printk in RTL
> code. You may get away with it *sometimes*, but it WILL come back to bite
> you later. Trust me on this, I know... printk is, of course, OK in the
> init_module and cleanup_module routines.
Okay great- I switched over to rtl_printf and will remain weary of printk.
> > Does anyone know what might be going wrong? Did the details
> > of periodicity changes from 2.2 to 2.4? Should I back
> > down to 2.2.19-rt-3.0?
>
> I can not provide you with many details of the issue right now, but
> I am sure that Michael B. can. I can, however, tell you how to fix the
> problem. Simply replace your use of "clock_gethrtime(CLOCK_REALTIME)" with
> a simple call to
> "gethrtime()" when calculating the value for "soon". The clock_gethrtime
> call includes a delta offset that is set at {insert Michael Bs wisdom here}
> time. Apparently that delta is not taken out, as would be necessary for
> this to work as you expected, from the pthread_make_periodic_np routine (or
> the scheduler... Michael?). This may or may not be a bug, we will have to
> see what the guys at FSM labs have to say about it.
>
> Please also note that you can use a simple call to gethrtime() in
> your periodic thread. This will remove the spinlock checking on the
> clock_gethrtime calls that is probably responsible for most of your delay.
> On my machine, before I made the change to a simple gethrtime() call (in the
> periodic task) I got:
>
> Delay of 384ns near 0ms
> Delay of 544ns near 27ms
> Delay of 576ns near 3456ms
> Delay of 608ns near 28972ms
> Delay of 640ns near 43328ms
> Delay of 704ns near 60545ms
> Delay of 768ns near 200830ms
> Delay of 960ns near 263810ms
>
> After switching to the simple gethrtime() (and thus removing some
> spinlock protection, which I believe is only needed for RTL kernel
> internals), I got:
>
> Delay of 160ns near 0ms
> Delay of 192ns near 1133ms
>
> You can decide which is better, but *I* know which *I* prefer. :-)
I switched to gethrtime() to get 'soon', and indeed periodicity
returns! In addition, switching all my clock reads to gethrtime() does
indeed reduce my early max delay times, by about the same amount
your's were improved. (~600ns->~200ns) Thank you.
However, after long enough I still see the monster glitches of >1.1ms,
which means even after all the details of the new kernel have been ironed
out, my initial bug remains.
Lets review- (on 2 different machines, P-200 & PII-450)
KERNEL- 2.2.14-rt2.2 (both) or 2.4.0.t1-rt-3.0.pre7 (PII-450 only)
both pretty minimal kernels - no APM or PNP in either
BIOS- set with no APM or PNP, and all kinds of other options (both cpus)
(disable serial & parallel,play with caching,error checking,etc.)
HARDWARE- all devices disconnected from PC except-
keyboard, mouse, video card, hard drive, floppy, (onboard sound?)
Every now and then, the cpu locks up for-
1.1-1.2 ms in the PII-450 case
.5- .6 ms in the P-200 case
(note that the faster machine glitches for for twice as long?)
> > -Chuck: who now has two problems where he once had one! :)
>
> Hopefully that number will be down to zero soon.
Well, we're back to one, but it's really getting me down. The other
machine I was testing this on (P-200) is unbootable at the moment. Can
anyone think of a reason I would see this on 2 machines, and at least 2
other people don't see it on theirs? As you may have inferred from
above, I believe it must be kernel, BIOS, or hardware. Regardless I've
tried dozens of different kernel configs in conjuction with dozens of
BIOS settings, and am completely out of ideas.
I have sound card _NOT_ supported in all versions, but could the onboard
sound be giving me problems? By default I'm running in X, but I've tried
it without X and the glitch remains. I'm bringing in a witchdoctor today.
He recommends some incense, 13 cloves of garlic, and 2 dead chickens.
I figure it can't hurt...
Chuck
-- [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/
