Hi, Denis Oliver Kropp wrote: > > (!) [ 1076: 19.429] --> Caught signal 4 (at 0xbe826a2c, illegal > > trap) <-- > > (!) FUSION_PROPERTY_LEASE --> Connection timed out > > (!) [ 1076: 19.521] --> Caught signal 11 (at (nil), invalid > > address) <-- > > Killed > > Do you also have kernel messages regarding this?
Unfortunately not now, I won't have access to the device again until the next week... > I'd like to have a Fusion Time which is implemented in the kernel > module and does the necessary (platform specific?) things to > provide a skewless runtime counter, maybe in the shared area to > avoid system calls. > > What other solutions are out there? Couldn't the driver just register a system device that would watch suspend/resume events, remember the jiffies before suspend, compute the difference and update all purchase_stamp values accordingly? > > (!) [VT Switcher 9.060] ( 1359) *** Assumption [core != > > NULL] failed *** > > [/home/zeitlin/src/rea/src/DirectFB/src/core/core.c:633 in > > dfb_core_suspend()] > > The assumption is ok. No harm. > > But why does it switch VTs? I assume the kernel switches away from the current VT prior to suspend so that it doesn't have to store console's content/state -- the app has to do it itself when its VT is activated again after resume, in exactly the same way it has to deal with the user pressing Ctrl-Alt-F?. > > Unfortunately, using no-vt-switching doesn't help much: we don't > > get that assumption failure above, but the app still receives > > SIGILL (on resume this time), with useless gdb backtrace. > > Please build with "--enable-trace" that maintains a copy of the > call stack and therefore even helps if you have stack corruption. Thanks for the tip! Regards, Vaclav -- PGP key: 0x465264C9, available from http://pgp.mit.edu/ _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
