public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: <henry.mahler@timedomain.com>, <ecos-discuss@ecos.sourceware.org>
Subject: RE: [ECOS] BSD socket stall
Date: Sat, 15 Sep 2012 17:44:00 -0000	[thread overview]
Message-ID: <BAY146-W643F364EA80F3FD01B89CCE4970@phx.gbl> (raw)
In-Reply-To: <CAH0LssbJX2f5U6wtxe+KjbqPZXDTJqPm8Awua6KC+o5oOxQx8Q@mail.gmail.com>


Hi Henry,
> We will try out this change but we have already changed our application 
> to have separate sockets for each thread. I not sure we could provide 
> answer to the question of does this change the fix this issue in our 
> case. 
> 
> I am just surprised that an issue like this could still be the BSD 
> after all these years. I mean ECOS and freeBSD stack have been out for 
> what 10+ years. I am I clueless for having assumed having two threads 
> send one socket was OK. I believed that sockets would be thread save, I 
> guess that is not the case. 
> Thanks, 
> Henry 
For UDP sockets that use case is perfectly OK.
You will see, the new version will handle this correctly,
except for the still possible priority inversion.
For TCP sockets the results are undefined, except
when the message size is always exactly 1 byte.

Why did that problem not occur before? Hard to tell.
For instance I believe that the problem arises from
interrupting this statement in sb_lock():
sb->sb_flags |= SB_WANT;
that will be an atomic like OR [bx],0x2 on Intel,
but at least 3 assembler instructions on ARM.
So you should have no problem at all on an Intel.
Although this is a perfect example of what happens,
when you use a condition object without a mutex.

But you should also check for Spurious interrupts.
They are likely to occur due to the "Tickle Loop"
in the BSD stack, especially when at a high rate.
My latest AT91 Ethernet driver does not need this
any more, and avoids the spurious interrupts even
if the stack polls the IRQ from time to time.

Therefore I would recommend you check this list of
important patches which we at Softing developed over
the last year (I must apologize, the list is too long,
but we walk on thin ice as you know, and most of these
bug fixes are obviously badly needed):
Bug   20804: Misbehavior of printf %e/%g format
Bug 1001522: Array index out of bounds in tftp_server.c
Bug 1001629: bsd stack uses wrong timeout values if hz != 100
Bug 1001633: DHCP Client may hang
Bug 1001634: A code review of dlmalloc.cxx revealed several weaknesses
Bug 1001635: wrong results from Cyg_StdioStream::read
Bug 1001637: fcntl() fails to handle F_GETFL, F_SETFL
Bug 1001639: Problems with i2c.cxx
Bug 1001641: Erase function in flashiodev.c and flashiodevlegacy.c handle "err_address" differently
Bug 1001645: Recursive Posix Mutexes
Bug 1001648: flash_init() behaves differently if CYGHWR_IO_FLASH_DEVICE==1
Bug 1001649: AT91 hal extension
Bug 1001654: diag_printf truncates the values in %llu and %llx formats
Bug 1001655: eth_drv_send stack_corruption with CYGFUN_LWIP_MODE_SIMPLE
Bug 1001656: FreeBSD: add AF_PACKET socket family
Bug 1001657: httpd server should parse request header lines
It might help to understand what is the application for this patches,
especially the new transacted PHY interface and the Packet sockets.
Think of PTPv2: Here we have to exchange very complex data over SMI
with the PHY, and the PTP packets may be in raw ethernet format.
That is what finally led to these enhancements.
Regards,
Bernd Edlinger 		 	   		  

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  parent reply	other threads:[~2012-09-15 17:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-08 17:43 henry mahler
2012-09-13 13:14 ` Bernd Edlinger
2012-09-13 21:02   ` Lambrecht Jürgen
     [not found] ` <BAY146-W727B35516EEA4449F4ECCE4910@phx.gbl>
     [not found]   ` <CAH0LssZ1+fGEESuzmZuRn0G+8D+yOcSaXu8ZBXruR36OUzdQxQ@mail.gmail.com>
2012-09-14  8:21     ` Bernd Edlinger
2012-09-14 14:19       ` Bernd Edlinger
     [not found]         ` <CAH0LssbJX2f5U6wtxe+KjbqPZXDTJqPm8Awua6KC+o5oOxQx8Q@mail.gmail.com>
2012-09-15 17:44           ` Bernd Edlinger [this message]
2012-09-14  8:21     ` Bernd Edlinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BAY146-W643F364EA80F3FD01B89CCE4970@phx.gbl \
    --to=bernd.edlinger@hotmail.de \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=henry.mahler@timedomain.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).