The following usually crashes after 2-3 minutes for me: # while true; do splash_manager -c demo -T Brontes --steps 3; done Also happens with the 2006.1 theme. After a while, the screen freezes at the end of the spash. I can ssh in and strace tells me that splash_manager is sitting on wait4(). The only child of splash_manager is chvt. When I attempt to attach strace the chvt process, I get nothing useful: Process 23450 attached - interrupt to quit dup(2) = 4 fcntl(4, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) brk(0) = 0x502000 brk(0x523000) = 0x523000 fstat(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 1), ...}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b79aab24000 lseek(4, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(4, "VT_WAITACTIVE: Interrupted syste"..., 39) = 39 close(4) = 0 munmap(0x2b79aab24000, 4096) = 0 exit_group(1) = ? Process 23450 detached Alt+SysRQ+t shows: chvt S ffff81006ad3dc88 0 25679 25646 (NOTLB) ffff81006ad3dc88 ffff81006ad3dca8 000000038020d2df 0000000000000082 ffff81007bf10140 ffff810072e809b0 0000000000000765 ffff81007bf10318 0000000200000000 ffff81006ad3dc68 ffffffff80286d74 0000000300000000 Call Trace: [<ffffffff80286d74>] __wake_up_common+0x44/0x80 [<ffffffff803a8485>] vt_waitactive+0xa5/0xf0 [<ffffffff802884b0>] default_wake_function+0x0/0x10 [<ffffffff803a9628>] vt_ioctl+0x1158/0x18e0 [<ffffffff8020ec10>] link_path_walk+0x100/0x140 [<ffffffff80207709>] find_get_page+0x29/0x60 [<ffffffff8023b0bd>] tty_ioctl+0xd1d/0xde0 [<ffffffff80208b5e>] __handle_mm_fault+0x59e/0x9e0 [<ffffffff8024e1ca>] chrdev_open+0x18a/0x1e0 [<ffffffff80222ba1>] __up_read+0x21/0xb0 [<ffffffff8020ac17>] do_page_fault+0x447/0x820 [<ffffffff802458c9>] do_ioctl+0x69/0xa0 [<ffffffff80232322>] vfs_ioctl+0x2a2/0x2e0 [<ffffffff802515f9>] sys_ioctl+0x49/0x80 [<ffffffff802646e2>] system_call+0x7e/0x83
vt_waitactive() sits in a loop until the foreground console is the requested one. So I guess the point of failure is some point earlier: chvt requests a VT change (which somehow gets ignored/lost), then its sits in this loop.
This would appear to be a concurrency issue as the splash_manager demo loop runs for as long as I have tested when a UP kernel is built. This system has 4 CPU's.
Fixed in 1.3.1. Thanks for your help Daniel :)
