Hi Greg,
On Fri, Nov 30, 2007 at 10:03:36AM +1000, Greg Ungerer wrote:
>
> I have no specific answer to what might be wrong...
>
> But from the trace below it looks like you are using threads.
> I would try to test your code without this first if this is the case.
> Threads has a history of problems on uClinux, and it may well
> be broken for you.
the "signal" problem is independent of threads, and I could reproduce
this on a regular (nun-uC) linux system, too. However, it also worked
from time to time - a bit strange.
> Also I didn't see you set the stty settings of the serial
> port you are using/testing (ttyS0)? Do you know it is
> setup the way you want?
For the test program from the post: no, I am not sure, but the behaviour
of bluntly crashing after the interrupted system call should not be
caused by a port setup either, I think.
> You don't need to do some signal magic to get around a
> blocking read. Just set the port up in raw mode with
> appropriate vmin/vtime settings and the read will no block.
> But maybe you are just doing this to test?
Yes, this was just a test in this case.
For the history: in the beginning (with the old uClinux distribution I
used), I could not get pthreads to work. So I set up several processes
to do the work, and two of them had to do with the serial port, one of
them being sent a SIGUSR1 from time to time to start (or even stop)
sending/receiving on the serial port. This was when I got these problems...
Then, using pthreads, this got needless, but nevertheless I got caught
by it on the first tests with the old code.
> The console device can be defined on the kernel command line,
> with something line "console=ttyS2". Of course hacking the
> driver will also work :-)
Well, another thing I did not really find out yet - but maybe I simply
ran into the startup problems with _copy_romfs, because whenever I left
out my "driver hacking" and set "console=ttyS2" I simply got no output
from the kernel at all and - since no other connection exists - did not
see if it was running (*sigh* at that time I did not yet figure out how
to check where the processor was looping with the BDM debugger... I will
catch up on this tomorrow and check if the hack is still needed).
But still at least for the console stuff, I remember there were 2 or 3
base address assignments missing for ports >= ttyS2 in the driver.
My tree is quite messy at the moment, so I can not provide a proper patch
for the latter, but tomorrow I could look for these lines and post them
here.
The other "read" problem I supposed to have did dissolve itself after I
recognized that it is a stupid idea to let the main thread run in an
idle "while(1) {}" loop when the real task is not implemented yet - stupid
me did not think it would really eat up _all_ processing power (seemingly
not even the kernel got any cpu time back).
> Regards
> Greg
Regards,
Wolfgang
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
