Philippe Gerum wrote: > On Fri, 2006-11-24 at 11:41 +0100, Jan Kiszka wrote: >> Peter Soetens wrote: >>> On Thursday 23 November 2006 16:25, Daniel Schnell wrote: >>>> One of the next steps would be finding out which actual function back >>>> trace the suspicious thread has. So I execute gdb and try to attach to >>>> the appropriate process, which works. Problem: sending Ctrl-C doesn't >>>> work, independant of if gdb is executed via ssh or serial console. So I >>>> cannot stop the actual program beeing debugged, rendering the gdb >>>> approach useless. Also sending SIGINT to the GDB process doesn't work. >>>> It seems to be simply ignored. As I understand CTRL-C is effectively >>>> sending SIGINT and is sent to GDB itself and not to the underlying appl. >>> We had a similar issue while debugging an RTNET app (main thread + 1 >>> xenomai >>> posix skin thread) under xenomai. I don't recall exactly the circumstances, >>> but the app was blocked on a socket, and a Ctrl-C did not work. A 'killall >>> gdb' (SIGTERM) did come through and killed gdb. If you (the Xeno/RTNet >>> developers)'re interested in this case, I'll see if I can get more info. >> You're welcome. >> >> I just checked the behaviour of examples/xenomai/posix/eth_p_all over >> gdb. I can interrupt the blocking recv - so far so good - but the >> syscall is unfortunately not replayed when continuing. Instead, the >> program just terminates because some error (EINTR) is reported to the >> application. >> >> [Too lazy to dig:] Philippe, isn't syscall restarting after an >> interruption the job of the Xenomai nucleus? > > Yes, it is, and normally, it does so. > > syscall(): > return -EINTR > do_hi/lo_syscall_event(): > request_syscall_restart(): > if (syscall_return == -EINTR) pass back -ERESTARTSYS > Linux ret_from_syscall: > do_notify_resume upon sig, which eventually checks for > -ERESTARTSYS then fixes $pc to restart the interrupted call. > This is regular Linux code, Xenomai relies on it, but does not > change it. > > Issue #1: a blocking Xenomai syscall does not detect the XNBREAK > condition properly upon return from xnpod_suspend_thread() or > xnsynch_sleep_on(), therefore does not pass back -EINTR to the nucleus > when this bit is raised for the current thread, which causes the signal > to be left over. Usually, the consequence of this is "please find the > reset button, and exercise your firmware once more". This said, weird > behaviour instead of total freeze has been experienced in this context, > too. > > Issue #2: user-space switches signal handling to SysV behaviour instead > of the BSDish one, thus preventing syscall restart in favour of getting > a failure return code with errno == -EINTR. Usually not the case, but, > this deserves a verification. > > Issue #3: Oops. We have a bug. >
I take (a variant of) #1 - RTnet bug... Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
