>Andy, have you tried using RTAI or Bob Lee's O(1)+low latency 2.4
>kernel? What bugs in 2.4 are you running into that aren't in 2.6? It
>has been my experience that 2.4 is largely more stable than 2.6 even
>on x86 (and there was 2.6 x86 support since 2.6.0). Which drivers
>have you had to backport?
>
>
>
No, I haven't looked into those kernels, but I may. Thanks very much
for the advice. Are those things that I can readily port to the
TS7250? I.e., are they their own kernel distro, or are they provided as
a set of patches to an existing kernel?
As far as drivers, I haven't backported any specifically that I need.
Rather that comment came from my reading code samples from other drivers
and/or books. Before I came to the realization that the 2.4 and 2.6
kernel driver models are significantly different, I was trying to get
2.6 methods to work under 2.4 in my own drivers (with obvious lack of
success).
My only "stability" problem right now that I'm wrestling with would
appear to be a bug in the sockets layer. I've got "stability" in
quotes, because there isn't anything else I can think of that's causing
the problem, although at this point, I haven't eliminated anything from
consideration. I described it in another post, but I'll do so
again--I'm definitely open to assistance!
I've got a program with a UDP socket that is in a while loop receiving
packets. Very infrequently (not very often--I would say after perhaps
1000 packets or more), I get a EINTR return from recvfrom instead of the
packet. No problem--BSD says that this is caused by a signal, and so my
code just retries. Problem is that in this circumstance I never get any
data back when I retry the recvfrom (I just reenter a blocking state for
the next packet), and once this happens on the socket, I'm pretty much
hosed, since all further receives on the socket return EINTR.
The interesting part of it is that the EINTR return value (and
subsequent unblock of recvfrom) are exactly synchronized with when I
should be getting the incoming packet. I know this because I'm
controlling the sending end, and I can set it to a specific frequency of
packets. Once it starts "ignoring" packets, I get the EINTRs at the
same rate and same timing that I'd get my normal packets. So it's
pretty darn unlikely that the EINTR is indicating a legitimate signal
interruption. Furthurmore, I've attached signal handlers to all the
signals that are in common use (the majority of the lower 64, except
SIGCHLD, SIGKILL, etc.), and none of those is getting triggered. Plus,
I'd think that if it was completely unhandled, that I'd probably end up
terminating. That's not to say that it still couldn't be some kind of
signal, but I'm unsure as to how. The only one that makes logic sense
would be SIGSEGV (i.e. my buffer pointer is corrupt/wrong), but I've
definitely got a handler on that to terminate the program, and I never
get the notification.
I've tried looking through the socket & signal code in the kernel. This
is very slow going, not being familiar with all the goop under the
hood. So far, it doesn't look to me like there's any other legitimate
reason for an EINTR error code, so I'm at a complete loss. This problem
is the one that I was thinking that there might be an updated kernel
that may fix the problem. I haven't been able to find a bug report that
describes my symptom, though, so it's mostly wishful thinking.
--Andy
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|