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
