Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm

["Samuel J. Greear" <sjg@xxxxxxxxxxxx>]

On Mon, Jul 26, 2010 at 8:32 PM, YONETANI Tomokazu <qhwt+dfly@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 ?? ()
>

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