This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

ramfs and serial line


Hi all,

I run the TFTP server from the eCos networking package server on a RAM
filesystem (block-based allocation). I have used wrappers to fopen(),
fclose(), fwrite() and fread() to implement the file operations.

In the first place this works. But if I have a second, independent thread
which waits for input from the serial line, using fgetc(), there is a fatal
problem:

A TFTP GET request for an existing file on ramfs is not answered, because
the TFTP server calls fread(), and fread() does not return. It doesn't
crash, but seems to block eternally. (I have checked success of the fopen
for read. And all the call parameters for fread are also OK.)

TFTP PUT requests are correcty handled, and the files appear in the
directory and can be read from the ramfs.

I remember an earlier problem that came from the conjunction of
Cyg_StdioStream::refill_read_buffer() and cyg_libc_stdio_flush_all_but().
The former routine locks the stream and calls cyg_stdio_read() which blocks
on a condition variable, waiting for characters coming from the underlying
device. Then, another thread calls something that implies
cyg_libc_stdio_flush_all_but() which spins trying to flush the other
(locked) stream. I suspect that fread() implies
cyg_libc_stdio_flush_all_but().

I have some debugging problems on my SH3 target, so I'm not yet sure if
this can be the cause of the problem. Has anybody experience, if blocking
for serial input can cause lockup in an other thread's read operations on a
different device? (If so, that would be a major problem)

Bye, Peter



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]