[En-Nut-Discussion] Fingerprints found at crime site....
Jesper Hansen
jesperh at telia.com
Wed Jun 28 00:11:40 CEST 2006
Thread Lurker says:
Fantastic detective work, Michael !
I'll try apply all these latest mods and see if it helps solve my problems.
/J
Michael Jones wrote:
> Hello,
>
> After some serious head banging I found this little peace of DNA at the site
> of the crime: "...{.R1-*}{.R1-*}{.RS.O.O.O..." - The forensic lab was in
> tumult...
>
> With this little sequence it was possible to locate the exact spot of the
> crime and take some quite distinct fingerprints (see:
> http://private.l-s-b.de:81/evidence.png).
>
>
>
> The simplest way to "fix" this (for verification of problem only) is:
>
> int NutEventWait(volatile HANDLE * qhp, u_long ms)
> {
> NUTTHREADINFO *tdp;
>
> /* Get the queue's root atomically. */
>
> NutEnterCritical(); // <===================== Patch
> tdp = *qhp;
>
> /*
> * Check for posts on a previously empty queue.
> */
> if (tdp == SIGNALED) {
> /*
> * Even if already signaled, switch to any other thread, which
> * is ready to run and has the same or higher priority.
> */
> *qhp = 0;
> NutExitCritical(); // <===================== Patch
>
> NutThreadYield();
> return 0;
> }
> /*
> * Remove the current thread from the list of running threads
> * and add it to the specified queue.
> */
> NutThreadRemoveQueue(runningThread, &runQueue);
> NutThreadAddPriQueue(runningThread, (NUTTHREADINFO **) qhp);
>
> NutExitCritical(); // <===================== Patch
>
> .
> .
> .
>
> But, as the problem is in NutThreadAddPriQueue(...) I propose the following
> less Critical-Section intensive version (which possibly can be further
> refined):
>
> void NutThreadAddPriQueue(NUTTHREADINFO * td, NUTTHREADINFO * volatile
> *tqpp)
> {
> NUTTHREADINFO *tqp;
>
> td->td_queue = (HANDLE) tqpp;
> td->td_qpec = 0; // start with clean event count
>
> NutEnterCritical();
> tqp = *tqpp;
>
> if (tqp == SIGNALED) {
> tqp = 0;
> td->td_qpec++; // transfer the signaled state
> } else if (tqp) {
> NutExitCritical(); // there are other threads in queue
> // so its save to leave
> critical.
>
> while (tqp && tqp->td_priority <= td->td_priority) {
> tqpp = &tqp->td_qnxt;
> tqp = tqp->td_qnxt;
> }
>
> NutEnterCritical(); // back into critical
> }
>
> td->td_qnxt = tqp;
>
> *tqpp = td;
> if (td->td_qnxt && td->td_qnxt->td_qpec) {
> td->td_qpec += td->td_qnxt->td_qpec; // don't overwrite count
> td->td_qnxt->td_qpec = 0;
> }
> NutExitCritical();
> }
>
> With this change I feel confident that we have finally got to the bottom of
> the problem! Bashing the OS with massive amounts of ARP & Random packets
> (about 25% utilization of 100Mbps) has virtually no effect any more - just
> the to be expected decrease of throughput (actually one of our Linux
> machines stopped dead during the test - probably something that it ate).
>
>
>
> Cu,
> Michael
>
>
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>
>
More information about the En-Nut-Discussion
mailing list