On Mon, Jul 26, 2010 at 8:32 PM, YONETANI Tomokazu <qhwt+d...@les.ath.cx> wrote: > On Mon, Jul 26, 2010 at 06:04:00PM -0600, Samuel J. Greear wrote: >> I've pushed some fixes into master, >> >> Commit 0f2e13efc9137bb21562ef4093049fd044651429 should fix the screen issue. > > I updated the kernel with the latest source (the world has been installed > from the source as of 4cc93e2d), but I'm afraid it doesn't fix the issue. > Here's how you compile GNU screen from git master, by the way: > > $ git clone git://git.sv.gnu.org/screen.git > $ cd screen.git/src > $ autoreconf && ./configure && gmake && ./screen > (and press ctrl+D or type `exit' followed by Enter key) > > An window still takes about 10-seconds before closing if it was running > a shell. The shell process itself is terminated right after pressing > ctrl+D, according to the output from ps command. Bisecting revealed that > the first commit in GNU screen which takes longer to close a shell window > on a recent DragonFly kernel is: > http://git.savannah.gnu.org/cgit/screen.git/commit/?id=33b7c9ca > > > I also noticed that issuing shutdown command from within screen triggers > a kernel panic, if it proceeds within the 10-seconds delay. I don't use a > special CFLAGS to build the kernel, and I use gcc4.1 (no CCVER specified). > > Fatal trap 12: page fault while in kernel mode > mp_lock = 00000001; cpuid = 1; lapic.id = 01000000 > fault virtual address = 0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x0 > stack pointer = 0x10:0xd3686a80 > frame pointer = 0x10:0xd3686aa8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4436 (screen) > current thread = pri 38 (CRIT) > <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 00000001; cpuid = 1 > Trace beginning at frame 0xd3686980 > panic(ffffffff) at panic+0x14f > panic(c0332c96,c0345fcc,0,0,fffff) at panic+0x14f > trap_fatal(0,0,cfaf7310,d274b650,c) at trap_fatal+0x31d > trap_pfault(26,0,0,d3a51f28,d25363d0) at trap_pfault+0xff > trap(d3686a38) at trap+0x7a0 > calltrap() at calltrap+0xd > --- trap 0, eip = 0, esp = 0xd3686a7c, ebp = 0xd274b650 --- > (null)(0,cfaac418,0,cc476400,0) at 0 > CPU_prvspace() at CPU_prvspace+0x8054 > boot() called on cpu#1 > Uptime: 20m42s > #0 _get_mycpu (di=0xc042b2a0) at ./machine/thread.h:83 > #1 md_dumpsys (di=0xc042b2a0) > at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263 > #2 0xc01a24a1 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:839 > #3 0xc01a2a73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388 > #4 0xc01a2fd6 in panic (fmt=0xc0332c96 "%s") > at /usr/src/sys/kern/kern_shutdown.c:745 > #5 0xc030611d in trap_fatal (frame=0xd3686a38, eva=<value optimized out>) > at /usr/src/sys/platform/pc32/i386/trap.c:1125 > #6 0xc030622e in trap_pfault (frame=0xd3686a38, usermode=0, eva=0) > at /usr/src/sys/platform/pc32/i386/trap.c:1026 > #7 0xc03076e8 in trap (frame=0xd3686a38) > at /usr/src/sys/platform/pc32/i386/trap.c:713 > #8 0xc02f2427 in calltrap () > at /usr/src/sys/platform/pc32/i386/exception.s:785 > #9 0x00000000 in ?? () >
This 10-second-wait should be fixed with commit 847ff8c. While debugging I noticed screen calls close(2) on all descriptors except stdin/err/out every time it forks. Making it use DragonFly's closefrom(2) would be a great optimization that would reduce new window creation times, if anyone felt so inclined. Sam