Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Tue, Jul 20, 2010 at 6:48 AM, Matthew Dillon dil...@apollo.backplane.com wrote: Sam's select/poll infrastructure removal project is now in HEAD. This project reimplements the kernel's select() and poll() system calls using per-thread kqueues and removes the original select/poll infrastructure. We expect there to be some bugs so anyone running HEAD please report issues where (primarily) programs wind up blocking on something and not waking up when they should, or if the system crashes or deadlocks when it did not before. I have kept my Backup server from upgrading because of this. I am running the development version. Is it ok to upgrade to current? thanks :-) --Siju
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
:I have kept my Backup server from upgrading because of this. I am :running the development version. Is it ok to upgrade to current? : :thanks :-) : :--Siju We are still finding bugs but I think 95% of the problems have been dealt with. Both TheShell and Avalon has been up 3.5 days running recent kernels. I recommend setting up a /boot/kernel.bak/ directory with your working kernel+modules and then go ahead and upgrade to master. The more real machines we have running it the faster we can get it release-ready. -Matt Matthew Dillon dil...@backplane.com
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Tue, Aug 31, 2010 at 9:52 AM, Matthew Dillon dil...@apollo.backplane.com wrote: :On Sun, Aug 01, 2010 at 03:01:41AM -0600, Samuel J. Greear wrote: : This 10-second-wait should be fixed with commit 847ff8c. : :Apparently the recent commit (within a week or so) re-introduced this :10-second-wait. On the other hand, the kernel built from the very recent :master no longer panics when I reboot the PC while GNU screen is running. I am going to guess that this has to do with the changes I made to TS_ZOMBIE in a recent patch. Those changes fixed traditional pty's, they were blowing up on us testing with telnet (ssh uses unix-98 pty's). I will try to reproduce the issue. -Matt Matthew Dillon dil...@backplane.com I originally fixed this with, http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/847ff8ce751358d6954bc9ea35d6513da665da3e http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/41cf5266ef48f9872e14b8d5707530a54161f3d5 Matt's recent commit http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/f454b4592466e584e6c5d54a579c8aa226a002da effectively un-did the prior fix. I just had the brilliant (sarcasm) thought to check the original poll function, it seems to use a magic combination of TS_CONNECTED and TS_CARR_ON to determine whether to set POLLHUP. I guess this is probably what we should go back to in the kq filters for pty's, but someone should make sure it does the right thing with consideration given to the POLLHUP/EV_EOF filtering recently introduced in the poll copyout function. I'll give this a looking over and make a commit in the next few days unless someone beats me to it. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
Hi, On Mon, Aug 02, 2010 at 07:23:35AM -0600, Samuel J. Greear wrote: 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 Referenced commit broke xterm (maybe other things). I have just pushed a fix to master. Confirmed that it's fixed, too. I didn't notice that some of changes after 847ff8c needed rebuilding the world (or libc) until recently, so I've been trying to investigate a few new problems which turned out to be caused by inconsistency between kernel and the library :) Thanks.
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
Thanks. After latest fixes, the xterm issue was sorted out as well as another one that later appeared with xulrunner. Cheers, Antonio Huete 2010/8/2 Samuel J. Greear s...@evilcode.net: Referenced commit broke xterm (maybe other things). I have just pushed a fix to master. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
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 Referenced commit broke xterm (maybe other things). I have just pushed a fix to master. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
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 = 0001; cpuid = 1; lapic.id = 0100 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 0xf, 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 = 0001; cpuid = 1 Trace beginning at frame 0xd3686980 panic() at panic+0x14f panic(c0332c96,c0345fcc,0,0,f) 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 0x 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
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On 7/27/2010 2:04, Samuel J. Greear wrote: Commit 44aa8f0264c19830b9f6fd1de53c456054f85b53 should fix the issues everyone was having with dhclient being slow. Yes, dhclient behavior seems to be back to normal. Sascha
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
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 = 0001; cpuid = 1; lapic.id = 0100 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 0xf, 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 = 0001; cpuid = 1 Trace beginning at frame 0xd3686980 panic() at panic+0x14f panic(c0332c96,c0345fcc,0,0,f) 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 0x in ?? () The big difference it seems, between screen from pkgsrc and screen's master branch is that the latter uses domain sockets on the file system instead of named fifo's. As a temporary workaround it should be possible to force it to use named fifo's instead of sockets. (I didn't try). Still looking into the issue. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Sat, Jul 24, 2010 at 11:30 AM, Samuel J. Greear s...@evilcode.net wrote: I know where this bug is and am working on a fix. dhclient I am fairly certain is the same issue only in the pipe code instead of the FIFO code (where the screen problem is). I will follow up here when I have a patch. Sam. On 7/24/10, YONETANI Tomokazu qhwt+d...@les.ath.cx wrote: On Fri, Jul 23, 2010 at 09:16:56AM -0600, Samuel J. Greear wrote: This only seems to happen on recent master with screen installed from a package. I was unable to reproduce with screen compiled from pkgsrc. Sorry, I realized I've been using the development version of GNU screen for virtical split, not the one from pkgsrc. The pkgsrc version or official screen-4.0.3 don't have the problem. Besides that, sched.c in 4.0.3 and Git master are identical except for the comment at the beginning. I'll start bisecting the Git repository of GNU screen tomorrow. I've pushed some fixes into master, Commit 0f2e13efc9137bb21562ef4093049fd044651429 should fix the screen issue. Commit 44aa8f0264c19830b9f6fd1de53c456054f85b53 should fix the issues everyone was having with dhclient being slow. Best, Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
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 = 0001; cpuid = 1; lapic.id = 0100 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 0xf, 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 = 0001; cpuid = 1 Trace beginning at frame 0xd3686980 panic() at panic+0x14f panic(c0332c96,c0345fcc,0,0,f) 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 0x in ?? ()
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 09:16:56AM -0600, Samuel J. Greear wrote: This only seems to happen on recent master with screen installed from a package. I was unable to reproduce with screen compiled from pkgsrc. Sorry, I realized I've been using the development version of GNU screen for virtical split, not the one from pkgsrc. The pkgsrc version or official screen-4.0.3 don't have the problem. Besides that, sched.c in 4.0.3 and Git master are identical except for the comment at the beginning. I'll start bisecting the Git repository of GNU screen tomorrow.
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
I know where this bug is and am working on a fix. dhclient I am fairly certain is the same issue only in the pipe code instead of the FIFO code (where the screen problem is). I will follow up here when I have a patch. Sam. On 7/24/10, YONETANI Tomokazu qhwt+d...@les.ath.cx wrote: On Fri, Jul 23, 2010 at 09:16:56AM -0600, Samuel J. Greear wrote: This only seems to happen on recent master with screen installed from a package. I was unable to reproduce with screen compiled from pkgsrc. Sorry, I realized I've been using the development version of GNU screen for virtical split, not the one from pkgsrc. The pkgsrc version or official screen-4.0.3 don't have the problem. Besides that, sched.c in 4.0.3 and Git master are identical except for the comment at the beginning. I'll start bisecting the Git repository of GNU screen tomorrow. -- Sent from my mobile device
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Mon, Jul 19, 2010 at 06:18:52PM -0700, Matthew Dillon wrote: Sam's select/poll infrastructure removal project is now in HEAD. This project reimplements the kernel's select() and poll() system calls using per-thread kqueues and removes the original select/poll infrastructure. We expect there to be some bugs so anyone running HEAD please report issues where (primarily) programs wind up blocking on something and not waking up when they should, or if the system crashes or deadlocks when it did not before. After the select/poll change, closing a window in GNU screen takes about 10 second if the program running in that window was either /bin/sh, /bin/csh, or /bin/tcsh. Top doesn't take 10 second to terminate, so it appears like specific to shells, but bash from pkgsrc is also not affected. I attached gdb to the backend process of GNU screen and found that the 10-second delay is caused by the call to select() in sched(). Cheers.
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On 7/20/2010 3:18, Matthew Dillon wrote: Sam's select/poll infrastructure removal project is now in HEAD. This project reimplements the kernel's select() and poll() system calls using per-thread kqueues and removes the original select/poll infrastructure. We expect there to be some bugs so anyone running HEAD please report issues where (primarily) programs wind up blocking on something and not waking up when they should, or if the system crashes or deadlocks when it did not before. I've already mentioned it on IRC, so just for the record. Since the select/poll work, svn doesn't work properly. For example: svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm times out while on a system from the 19th it succeeds. Another thing I noticed is that dhclient takes longer now (more tries) to get an IP (though it eventually succeeds). Regards, Sascha
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On 7/23/2010 13:56, Sascha Wildner wrote: I've already mentioned it on IRC, so just for the record. Since the select/poll work, svn doesn't work properly. For example: svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm times out while on a system from the 19th it succeeds. Sam's last commit (21ae0f4cfc832379591734bebfb53ae170b3b1e9) fixed that. svn now works again as expected. Another thing I noticed is that dhclient takes longer now (more tries) to get an IP (though it eventually succeeds). This is still kind of an issue. All I can say is that before the select work, it felt different. For example, on my latest boot of the box (with the aforementioned commit) it goes: Jul 23 15:16:11 console.info zoot kernel: DHCPREQUEST on re0 to 255.255.255.255 port 67 Jul 23 15:16:11 console.info zoot kernel: DHCPREQUEST on re0 to 255.255.255.255 port 67 Jul 23 15:16:11 console.info zoot kernel: DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 6 Jul 23 15:16:11 console.info zoot kernel: DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 13 Jul 23 15:16:11 console.info zoot kernel: DHCPOFFER from 192.168.0.1 Jul 23 15:16:11 console.info zoot kernel: DHCPREQUEST on re0 to 255.255.255.255 port 67 Jul 23 15:16:11 console.info zoot kernel: DHCPREQUEST on re0 to 255.255.255.255 port 67 Jul 23 15:16:11 console.info zoot kernel: DHCPACK from 192.168.0.1 Jul 23 15:16:11 console.info zoot kernel: bound to xxx.xxx.xxx.xxx -- renewal in 21600 seconds. Regards, Sascha
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 4:30 AM, YONETANI Tomokazu qhwt+d...@les.ath.cx wrote: On Mon, Jul 19, 2010 at 06:18:52PM -0700, Matthew Dillon wrote: Sam's select/poll infrastructure removal project is now in HEAD. This project reimplements the kernel's select() and poll() system calls using per-thread kqueues and removes the original select/poll infrastructure. We expect there to be some bugs so anyone running HEAD please report issues where (primarily) programs wind up blocking on something and not waking up when they should, or if the system crashes or deadlocks when it did not before. After the select/poll change, closing a window in GNU screen takes about 10 second if the program running in that window was either /bin/sh, /bin/csh, or /bin/tcsh. Top doesn't take 10 second to terminate, so it appears like specific to shells, but bash from pkgsrc is also not affected. I attached gdb to the backend process of GNU screen and found that the 10-second delay is caused by the call to select() in sched(). Cheers. Yonetani, I apologize, I am not a screen user, can you tell me the appropriate magic incantation to reproduce this? Best, Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 5:56 AM, Sascha Wildner s...@online.de wrote: On 7/20/2010 3:18, Matthew Dillon wrote: Sam's select/poll infrastructure removal project is now in HEAD. This project reimplements the kernel's select() and poll() system calls using per-thread kqueues and removes the original select/poll infrastructure. We expect there to be some bugs so anyone running HEAD please report issues where (primarily) programs wind up blocking on something and not waking up when they should, or if the system crashes or deadlocks when it did not before. I've already mentioned it on IRC, so just for the record. Since the select/poll work, svn doesn't work properly. For example: svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm times out while on a system from the 19th it succeeds. Another thing I noticed is that dhclient takes longer now (more tries) to get an IP (though it eventually succeeds). Regards, Sascha I have just committed a patch to master that fixes svn and may very well fix other issues. I am currently at a loss regarding dhclient as it is working fine in my test environments. All those that can confirm or deny that it is worse after the recent kq merge into master, it would be appreciated. Sam
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
Hi, On Fri, Jul 23, 2010 at 07:35:24AM -0600, Samuel J. Greear wrote: After the select/poll change, closing a window in GNU screen takes about 10 second if the program running in that window was either /bin/sh, /bin/csh, or /bin/tcsh. ?Top doesn't take 10 second to terminate, so it appears like specific to shells, but bash from pkgsrc is also not affected. This turned out to be wrong, bash seems to be affected too. I apologize, I am not a screen user, can you tell me the appropriate magic incantation to reproduce this? To reproduce it is easy; install misc/screen from pkgsrc, start it, press Enter to skip the banner, and type `exit' inside it. It usually won't take more than a few second before the shell terminates. Anyway, I'm giving your latest commit a try to see if it's related. Thanks.
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
Anyway, I'm giving your latest commit a try to see if it's related. Unfortunately, 21ae0f4c doesn't seem to fix my problem.
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Fri, Jul 23, 2010 at 8:26 AM, YONETANI Tomokazu qhwt+d...@les.ath.cx wrote: Anyway, I'm giving your latest commit a try to see if it's related. Unfortunately, 21ae0f4c doesn't seem to fix my problem. This only seems to happen on recent master with screen installed from a package. I was unable to reproduce with screen compiled from pkgsrc. Looking into it. Sam
