Hi Wolfgang,
Wolfgang Wegner wrote:
after already thinking all the basic problems should be solved, I found
a new one which I have no idea how to further debug it...
I have the problem that my hardware has an unusual port layout; the
console is at ttyS2 (MCF UART3), ttyS0 is a communication link. I
managed to get ttyS2 working as the console port (see the end for
details), but am not sure if ttyS0 is really OK.
My application now uses ttyS0, it behaves strange as soon as I read from
ttyS0. Depending on the application, either the complete system locks
up when I call read(), or at least the application behaves strange
(although the values read seem to be OK).
That's what the test application looks like (many printf's to see what is
going on, I know...):
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.
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?
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?
The console device can be defined on the kernel command line,
with something line "console=ttyS2". Of course hacking the
driver will also work :-)
Regards
Greg
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <strings.h>
#include <signal.h>
void dummy_handler(int signal) {
fprintf(stderr, "main received signal %x\n",signal);
return;
}
int main() {
int port, retval;
unsigned char read_val;
pid_t pid;
struct sigaction sigint;
pid = getpid();
printf("own pid: %d\n",pid);
pid = getppid();
printf("parent pid: %d\n",pid);
sigint.sa_handler = dummy_handler;
if(sigaction(SIGUSR1, &sigint, NULL) < 0) {
fprintf(stderr, "could not set up signal handler for SIGUSR1\n");
}
port = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
if(port < 0) {
printf("could not open port /dev/ttyS0\n");
exit(1);
}
else
printf("port open\n");
retval = read(port, &read_val, 1);
if(retval == 1)
printf("read successful, val = 0x%x\n",read_val);
else
printf("read error %x (%s)\n",errno, strerror(errno));
read_val = 0x10;
retval = write(port, &read_val, 1);
if(retval == 1)
printf("write successful, val = 0x%x\n",read_val);
else
printf("write error %x (%s)\n",errno, strerror(errno));
close(port);
exit(0);
}
And this is what happens:
/> test2 &
[27]
/> 00027 : pthread_initialize: initial thread stack bounds: bos=0x1, tos=0x41f80
000
own pid: 27
parent pid: 26
port open
kill -SIGUSR1 27
/> main received signal a
sh 26: Child 27 died
test2 &
[29]
/> 00029 : pthread_initialize: initial thread stack bounds: bos=0x1, tos=0x41f80
000
own pid: 29
parent pid: 26
port open
kill -SIGUSR1 29
main received signal a
/> kill -9 29
/>
So the application terminates after having caught the SIGUSR1, and when
I start it again, there seem to be even more problems, because I can not
even kill it any more.
Any hints what might go wrong here are - as usual... - greatly
appreciated!
Thank you,
Wolfgang
PS: I just checked and saw the same behaviour on a "regular" linux
machine, but still I do not understand what is wrong. On my real"
application the problem exists without the SIGUSR1 as the trigger,
but simply when calling the (blocking) read().
/**
NOTE:
Because I did not get this setup of ttyS2 as the console with the kernel
command line, I hacked mcfserial.c to accomplish this:
int mcfrs_console_setup(struct console *cp, char *arg)
{
int i, n = CONSOLE_BAUD_RATE;
mcfrs_console_port = 2;
mcfrs_console_baud = 115200;
mcfrs_console_cbaud = 2 | CBAUDEX;
mcfrs_init_console(); /* make sure baud rate changes */
return(0);
(There were additional fixes for UART3 needed in mcfrs_init_console and
mcfrs_put_char, but this seems obvious to me)
**/
_______________________________________________
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
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
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
