From nobody  Tue Aug 18 05:01:35 1998
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id FAA10715;
          Tue, 18 Aug 1998 05:01:35 -0700 (PDT)
          (envelope-from nobody)
Message-Id: <199808181201.FAA10715@hub.freebsd.org>
Date: Tue, 18 Aug 1998 05:01:35 -0700 (PDT)
From: yasu@mrit.mei.co.jp
To: freebsd-gnats-submit@freebsd.org
Subject: (1) rlogin from some host to the FreeBSD host with very slow link.
    (ping reports around 200ms - 500ms delay)

>Number:         7658
>Category:       kern
>Synopsis:       (1) rlogin from some host to the FreeBSD host with very slow link.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 18 05:10:01 PDT 1998
>Closed-Date:    Sat Jul 21 22:29:05 PDT 2001
>Last-Modified:  Sat Jul 21 22:29:50 PDT 2001
>Originator:     WATANABE, Yasuhiko
>Release:        3.0-CURRENT
>Organization:
Matsushita Research Institute Tokyo, Inc.
>Environment:
FreeBSD waltz 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Tue Aug 18 19:53:20 JST 1998     yasu@waltz:/usr/src/sys/compile/WALTZ  i386
>Description:
When I use a FreeBSD box from slow link, kernel sometimes panics with the
procedure listed in `how to repeat the problem' part.
Here is the back trace got form a crash dump.

# gdb -k kernel.debug vmcore.6
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2543616
initial pcb at 2191f4
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x3e
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf01417dd
stack pointer           = 0x10:0xf5bdcf2c
frame pointer           = 0x10:0xf5bdcf50
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         = 334 (xemacs-20.4)
interrupt mask          = 
panic: from debugger
panic: from debugger

dumping to dev 50001, offset 111824
dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
---
#0  boot (howto=260) at ../../kern/kern_shutdown.c:286
286                                     dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=260) at ../../kern/kern_shutdown.c:286
#1  0xf011aa57 in panic (fmt=0xf01014c8 "from debugger")
    at ../../kern/kern_shutdown.c:427
#2  0xf01014e5 in db_panic (addr=-267118627, have_addr=0, count=-1, 
    modif=0xf5bdcdb0 "") at ../../ddb/db_command.c:432
#3  0xf01013c5 in db_command (last_cmdp=0xf0207af4, cmd_table=0xf0207954, 
    aux_cmd_tablep=0xf02165d4) at ../../ddb/db_command.c:332
#4  0xf0101552 in db_command_loop () at ../../ddb/db_command.c:454
#5  0xf0103c63 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6  0xf01c9041 in kdb_trap (type=12, code=0, regs=0xf5bdcef0)
    at ../../i386/i386/db_interface.c:157
#7  0xf01d4553 in trap_fatal (frame=0xf5bdcef0) at ../../i386/i386/trap.c:874
#8  0xf01d3ffc in trap_pfault (frame=0xf5bdcef0, usermode=0)
    at ../../i386/i386/trap.c:772
#9  0xf01d3c4f in trap (frame={tf_es = -172163056, tf_ds = -267124720, 
      tf_edi = -172713344, tf_esi = -172545792, tf_ebp = -172110000, 
      tf_isp = -172110056, tf_ebx = 0, tf_edx = -172110024, 
      tf_ecx = -172545792, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
      tf_eip = -267118627, tf_cs = 8, tf_eflags = 66178, tf_esp = -172713344, 
      tf_ss = -266304152}) at ../../i386/i386/trap.c:396
#10 0xf01417dd in fsync (p=0xf5b49a80, uap=0xf5bdcf84)
    at ../../kern/vfs_syscalls.c:2425
#11 0xf01d4813 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, 
      tf_esi = 3206272, tf_ebp = -272642224, tf_isp = -172109868, tf_ebx = 1, 
      tf_edx = -1, tf_ecx = 5, tf_eax = 95, tf_trapno = 7, tf_err = 7, 
      tf_eip = 272271697, tf_cs = 31, tf_eflags = 662, tf_esp = -272642252, 
      tf_ss = 39}) at ../../i386/i386/trap.c:1031
#12 0x103a8951 in ?? ()
#13 0xe6fdb in ?? ()
#14 0xe7059 in ?? ()
#15 0xe7099 in ?? ()
#16 0x2d7ad in ?? ()
#17 0x2b86c in ?? ()
#18 <signal handler called>
#19 0xe6740 in ?? ()
#20 0xe6740 in ?? ()
#21 0x1ac4c in ?? ()
#22 0x3237c in ?? ()
#23 0x326c3 in ?? ()
#24 0xeae6 in ?? ()
#25 0x33248 in ?? ()
#26 0x3266e in ?? ()
#27 0x326c3 in ?? ()
#28 0x3382b in ?? ()
#29 0x10550 in ?? ()
#30 0x30ef9 in ?? ()
#31 0x67962 in ?? ()
#32 0x67f69 in ?? ()
#33 0x182e7 in ?? ()
#34 0x1815c in ?? ()
#35 0x2fd08 in ?? ()
#36 0x17cbc in ?? ()
#37 0x17cd8 in ?? ()
#38 0x2fa09 in ?? ()
#39 0x17e6c in ?? ()
#40 0x2c74e in ?? ()
#41 0x2d151 in ?? ()
#42 0x109a in ?? ()

>How-To-Repeat:
(1) rlogin from some host to the FreeBSD host with very slow link.
    (ping reports around 200ms - 500ms delay)
(2) run xemacs(20.4 with mule extention) and suspend(^Z) the xemacs.
(3) type ^C several times. (At this point the terminal stops to accept
    any keys.)
(4) login to the FreeBSD host again(using new terminal)
(5) kill -HUP -1 (with normal user privilage)
    and kernel panic occurs.

>Fix:

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: freebsd-gnats-submit@FreeBSD.ORG, yasu@mrit.mei.co.jp
Cc:  Subject: Re: kern/7658: (1) rlogin from some host to the FreeBSD host with very slow link. (ping reports around 200ms - 500ms delay)
Date: Wed, 19 Aug 1998 09:31:17 +1000

 >When I use a FreeBSD box from slow link, kernel sometimes panics with the
 >procedure listed in `how to repeat the problem' part.
 >Here is the back trace got form a crash dump.
 >....
 >#10 0xf01417dd in fsync (p=0xf5b49a80, uap=0xf5bdcf84)
 >    at ../../kern/vfs_syscalls.c:2425
 
 Here is a possible fix for the panic.
 
 diff -c2 vfs_syscalls.c~ vfs_syscalls.c
 *** vfs_syscalls.c~	Wed Jul 15 12:32:13 1998
 --- vfs_syscalls.c	Wed Aug 19 09:25:09 1998
 ***************
 *** 2423,2427 ****
   		VOP_UNLOCK(vp, 0, p);
   
 ! 		if ((vp->v_mount->mnt_flag & MNT_SOFTDEP) && bioops.io_sync)
   			(*bioops.io_sync)(NULL);
   	}
 --- 2423,2428 ----
   		VOP_UNLOCK(vp, 0, p);
   
 ! 		if (vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP) &&
 ! 		    bioops.io_sync)
   			(*bioops.io_sync)(NULL);
   	}
 
 Bruce

From: Bruce Evans <bde@zeta.org.au>
To: bde@zeta.org.au, freebsd-bugs@freebsd.org, yasu@codec.mrit.mei.co.jp
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/7658: (1) rlogin from some host to the FreeBSD host with very slow link. (ping reports around 200ms - 500ms delay)
Date: Sat, 22 Aug 1998 14:20:51 +1000

 >The following procedure still cause to hung terminal:
 >  >  (1) rlogin from some host to the FreeBSD host with very slow link.
 >  >      (ping reports around 200ms - 500ms delay)
 >  >  (2') type ^C several times. (At this point the terminal stops to accept
 >  >      any keys.)
 >
 >I did not mentioned but I rlogined 3 times.
 >      rlogin            rlogin              rlogin
 >Host A ----> Host B -----------------> Host C -----> Host D
 >FreeBSD      SunOS      slow link     Solaris       FreeBSD
 >
 >After I rlogined from Host A to Host D, if I type ^C several times,
 >then terminal seems to become frozen.
 
 I created a slow link using kernel pppd at 1200 bps, and couldn't see
 any problem for:
 
       rlogin            rlogin              rlogin
 Host A ----> Host B -----------------> Host A -----> Host B
 FreeBSD      FreeBSD    slow link     FreeBSD       FreeBSD
 
 The panic may have been caused by the following events:
 
 hangup -> revoked pty -> pty's vnodes lose their mount point ->
 kernel bug for fsync on vnodes with no mount point.
 
 FreeBSD returns -1/EIO for reading from revoked ptys instead of the
 more normal 0/no error.  Some broken applications spin reading -1/EIO.
 This may look like a hang.
 
 Bruce
State-Changed-From-To: open->closed 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 22:29:05 PDT 2001 
State-Changed-Why:  

From looking at the source on 5.0-CURRENT, it appears bde's fix made 
it's way into the tree. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=7658 
>Unformatted:
(2) run xemacs(20.4 with mule extention) and suspend(^Z) the xemacs.
(3) type ^C several times.
    At this point the terminal does not seem to work any more.
(4) login to the FreeBSD host again(using new terminal)
Fatal trap 12: page fault while in kernel mode
X-Send-Pr-Version: www-1.0

    (ping reports around 200ms - 500ms delay)
(2) run xemacs(20.4 with mule extention) and suspend(^Z) the xemacs.
(3) type ^C several times.
    At this point the terminal does not seem to work any more.
(4) login to the FreeBSD host again(using new terminal)
Fatal trap 12: page fault while in kernel mode
