From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 20:30:28 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88A7D16A417; Sun, 25 Nov 2007 20:30:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4AA13C45A; Sun, 25 Nov 2007 20:30:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IwO7O-000IYn-Ll; Sun, 25 Nov 2007 22:30:19 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lAPKUF6G064259; Sun, 25 Nov 2007 22:30:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lAPKUF7C064258; Sun, 25 Nov 2007 22:30:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Nov 2007 22:30:15 +0200 From: Kostik Belousov To: Rako Message-ID: <20071125203015.GF78396@deviant.kiev.zoral.com.ua> References: <47473E30.6070608@gmail.com> <20071124003453.O14018@fledge.watson.org> <47477F9F.2080900@gmail.com> <20071124142149.Y14018@fledge.watson.org> <47486C9B.4020407@gmail.com> <20071124211859.S14018@fledge.watson.org> <20071125075620.GA78396@deviant.kiev.zoral.com.ua> <4749B2CC.7020300@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1brTR8/mqxCEB6VZ" Content-Disposition: inline In-Reply-To: <4749B2CC.7020300@gmail.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 21b27277a002431422b7104c8bd6d4f1 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1827 [Nov 24 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org, Robert Watson Subject: snp panic [Was: Re: panic with tcpdrop] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2007 20:30:28 -0000 --1brTR8/mqxCEB6VZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 25, 2007 at 02:37:16PM -0300, Rako wrote: > It is not reproduceable. But a have 2 panic of that in 1 month. >=20 > The steps for the last panic: >=20 > watch -W /dev/ttyv0 > make buildkernel .... > Ctrl-G > Panic! >=20 > The explication from Kostik can be correct, but, if I not try to attach= =20 > again, only Ctrl-G; it is not the path for that explication or I=20 > misunderstands. Anyway, I can probe the changes for 1 month to test if=20 > any happen > Thanks! > Javier C-G seems to be the exact scenario for the bug. >=20 >=20 > >On Sat, Nov 24, 2007 at 09:19:42PM +0000, Robert Watson wrote: > >>On Sat, 24 Nov 2007, Rako wrote: > >> > >>>the patch solve the problem with tcpdrop, Thanks!! > >>> > >>>An other panic ocurred, but on other area, is on snp.ko module (watch = -W=20 > >>>/dev/ttyv0) but can't get backtrace. This panic is simliar at > >>> > >>>http://lists.freebsd.org/pipermail/freebsd-current/2007-March/069990.h= tml > >>> > >>>the problem may be at line 164 of /usr/src/sys/dev/snp/snp.c snp =3D= =20 > >>>ttytosnp(tp); > >>> > >>>where snp get NULL > >>> > >>>but, no familiar with this ... Any idea what can I do to solve the err= or? > >>I'm having trouble reproducing this -- could you give me a detailed set= =20 > >>of instructions regarding the specific steps I should take to try and g= et=20 > >>this panic, if it's reproduceable for you? > >> > >>Thanks, > >> > >>Robert N M Watson > >>Computer Laboratory > >>University of Cambridge > >> > >>>Regards, > >>>Javier > >>> > >>> > >>>Fatal trap 12: page fault while in kernel mode > >>>fault virtual address =3D 0x24 > >>>fault code =3D supervisor read, page not present > >>>instruction pointer =3D 0x20:0xc3e4f230 > >>>stack pointer =3D 0x28:0xd66c3b34 > >>>frame pointer =3D 0x28:0xd66c3b88 > >>>code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>> =3D DPL 0, pres 1, def32 1, gran 1 > >>>processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >>>current process =3D 2216 (make) > >>>trap number =3D 12 > >>>panic: page fault > >>>KDB: stack backtrace: > >>>db_trace_self_wrapper(c0a5f1ea,d66c39d4,c078878a,c0a5d5f4,c0b5bcc0,...= )=20 > >>>at db_trace_self_wrapper+0x26 > >>>kdb_backtrace(c0a5d5f4,c0b5bcc0,c0a1fb8c,d66c39e0,d66c39e0,...) at=20 > >>>kdb_backtrace+0x29 > >>>panic(c0a1fb8c,c0a7c54d,c3e44770,1,1,...) at panic+0xaa > >>>trap_fatal(c3e942b8,0,1,0,c39f5630,...) at trap_fatal+0x303 > >>>trap_pfault(0,c39f5630,c39f5630,0,c,...) at trap_pfault+0x250 > >>>trap(d66c3af4) at trap+0x382 > >>>calltrap() at calltrap+0x6 > >>>--- trap 0xc, eip =3D 0xc3e4f230, esp =3D 0xd66c3b34, ebp =3D 0xd66c3b= 88 --- > >>>snplwrite(c33bf800,d66c3c60,0,d66c3bbc,c0754bec,...) at snplwrite+0x80 > >>>ttywrite(c3389600,d66c3c60,0,c39cf5e8,c39f5630,...) at ttywrite+0x39 > >>>giant_write(c3389600,d66c3c60,0,0,c0abb080,...) at giant_write+0x6c > >>>devfs_write_f(c39cf5e8,d66c3c60,c3de4800,0,c39f5630,...) at=20 > >>>devfs_write_f+0x75 > >>>dofilewrite(d66c3c60,ffffffff,ffffffff,0,c39cf5e8,...) at=20 > >>>dofilewrite+0x97 > >>>kern_writev(c39f5630,1,d66c3c60,2813c076,0,...) at kern_writev+0x58 > >>>write(c39f5630,d66c3cfc,c,110,c337e630,...) at write+0x4f > >>>syscall(d66c3d38) at syscall+0x335 > >>>Xint0x80_syscall() at Xint0x80_syscall+0x20 > >>>--- syscall (4, FreeBSD ELF32, write), eip =3D 0x8083603, esp =3D=20 > >>>0xbfbfd4ec, ebp =3D 0xbfbfd528 --- > >>>Uptime: 19m14s > >>>Physical memory: 495 MB > >>>Dumping 86 MB: 71 55 39 23 7 > > > >I believe I have a plausible explanation for the panic. Please, look > >at the snpioctl(), SNPSTTY command. First, assume that both the s > 0 > >and snoop device has attached tty. Then, snp_tty will be overwritten, > >without detaching the old tty from the snooper. In this case, ttytosnp() > >would not find the snp from tty, returning NULL. This would lead to the > >trace above. This is old kernel bug. > > > >Now, I shall note that watch(8) does not attach to the new tty without > >detaching from the previous one. But, after destroy_dev_sched() conversi= on > >have been done for snp(4), actual detach is asynchronous. Since watch(8) > >opens the numbered snpX clone device instead of the master /dev/snp, it > >could reopen the same device. The condition is racy, and thus not easily > >reproducable. > > > >The patch below might help with kernel panic. > > > >diff --git a/sys/dev/snp/snp.c b/sys/dev/snp/snp.c > >index a84e90c..b8f3d63 100644 > >--- a/sys/dev/snp/snp.c > >+++ b/sys/dev/snp/snp.c > >@@ -491,7 +491,7 @@ snpioctl(struct cdev *dev, u_long cmd, caddr_t data,= =20 > >int flags, > > struct thread *td) > > { > > struct snoop *snp; > >- struct tty *tp, *tpo; > >+ struct tty *tp; > > struct cdev *tdev; > > struct file *fp; > > int s; > >@@ -502,6 +502,9 @@ snpioctl(struct cdev *dev, u_long cmd, caddr_t data,= =20 > >int flags, > > s =3D *(int *)data; > > if (s < 0) > > return (snp_down(snp)); > >+ if (snp->snp_tty !=3D NULL) > >+ return (EBUSY); > >+ > > if (fget(td, s, &fp) !=3D 0) > > return (EINVAL); > > if (fp->f_type !=3D DTYPE_VNODE || > >@@ -520,13 +523,6 @@ snpioctl(struct cdev *dev, u_long cmd, caddr_t data= ,=20 > >int flags, > > return (EBUSY); > >=20 > > s =3D spltty(); > >- > >- if (snp->snp_target =3D=3D NULL) { > >- tpo =3D snp->snp_tty; > >- if (tpo) > >- tpo->t_state &=3D ~TS_SNOOP; > >- } > >- > > tp->t_state |=3D TS_SNOOP; > > snp->snp_olddisc =3D tp->t_line; > > tp->t_line =3D snooplinedisc; --1brTR8/mqxCEB6VZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHSdtWC3+MBN1Mb4gRAu0rAJ9lkHv/pbEmxNcJT5qz0TngUdHjiwCcDnqW eoQ4RSTs4Sdh16Nsb6Vbf/c= =vC5x -----END PGP SIGNATURE----- --1brTR8/mqxCEB6VZ--