From owner-freebsd-current@FreeBSD.ORG Sun Nov 25 17:40:50 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 9DE4B16A468 for ; Sun, 25 Nov 2007 17:40:50 +0000 (UTC) (envelope-from rako29@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3F10F13C459 for ; Sun, 25 Nov 2007 17:40:50 +0000 (UTC) (envelope-from rako29@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so202544wra for ; Sun, 25 Nov 2007 09:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=c5/lKaSqEFxmD8sHLWQY5BZMUPdZBtsSO6vw624yU7Y=; b=pvQA5aKwX8jli0ggG8vnBifDRRJpzEnXKOBTYadUxOwZXYwh9ZZ4kbvYMRBBhimNMwdS5a5OmnXKhBQsFDzHHZvq+SJgSZ0XjB6dOk44ayg5KvuREMCqKeNTCPJdLivroNgQ08lXTrNpnDtCbkQhwY+PwZKHV8LD/o8Y2K31kBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WsuFVv+IypqJxvlkE6u5bDsI8N5svlgkQknWvU46go24nETcIwxybB638SGzQsYSurnyDKl6HBSqGw1a7Vsj2u0P79zzZnwLIABUXGA/9ruqExj0jjcUzYa4tUCiPYDFOIbs1nutVIohfLOw4iOffIj4ELXbdsYR0JU9HjoDaK4= Received: by 10.70.44.2 with SMTP id r2mr431081wxr.1196012449271; Sun, 25 Nov 2007 09:40:49 -0800 (PST) Received: from ?172.20.1.10? ( [190.188.78.77]) by mx.google.com with ESMTPS id i39sm2551556wxd.2007.11.25.09.40.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Nov 2007 09:40:48 -0800 (PST) Message-ID: <4749B2CC.7020300@gmail.com> Date: Sun, 25 Nov 2007 14:37:16 -0300 From: Rako User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <20071125075620.GA78396@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: 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 17:40:50 -0000 It is not reproduceable. But a have 2 panic of that in 1 month. The steps for the last panic: watch -W /dev/ttyv0 make buildkernel .... Ctrl-G Panic! The explication from Kostik can be correct, but, if I not try to attach again, only Ctrl-G; it is not the path for that explication or I misunderstands. Anyway, I can probe the changes for 1 month to test if any happen Thanks! Javier > 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 >>> /dev/ttyv0) but can't get backtrace. This panic is simliar at >>> >>> http://lists.freebsd.org/pipermail/freebsd-current/2007-March/069990.html >>> >>> the problem may be at line 164 of /usr/src/sys/dev/snp/snp.c snp = >>> ttytosnp(tp); >>> >>> where snp get NULL >>> >>> but, no familiar with this ... Any idea what can I do to solve the error? >> I'm having trouble reproducing this -- could you give me a detailed set of >> instructions regarding the specific steps I should take to try and get 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 = 0x24 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0xc3e4f230 >>> stack pointer = 0x28:0xd66c3b34 >>> frame pointer = 0x28:0xd66c3b88 >>> 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 = 2216 (make) >>> trap number = 12 >>> panic: page fault >>> KDB: stack backtrace: >>> db_trace_self_wrapper(c0a5f1ea,d66c39d4,c078878a,c0a5d5f4,c0b5bcc0,...) at >>> db_trace_self_wrapper+0x26 >>> kdb_backtrace(c0a5d5f4,c0b5bcc0,c0a1fb8c,d66c39e0,d66c39e0,...) at >>> 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 = 0xc3e4f230, esp = 0xd66c3b34, ebp = 0xd66c3b88 --- >>> 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 >>> devfs_write_f+0x75 >>> dofilewrite(d66c3c60,ffffffff,ffffffff,0,c39cf5e8,...) at 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 = 0x8083603, esp = 0xbfbfd4ec, >>> ebp = 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() conversion > 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, 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, int flags, > s = *(int *)data; > if (s < 0) > return (snp_down(snp)); > + if (snp->snp_tty != NULL) > + return (EBUSY); > + > if (fget(td, s, &fp) != 0) > return (EINVAL); > if (fp->f_type != DTYPE_VNODE || > @@ -520,13 +523,6 @@ snpioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, > return (EBUSY); > > s = spltty(); > - > - if (snp->snp_target == NULL) { > - tpo = snp->snp_tty; > - if (tpo) > - tpo->t_state &= ~TS_SNOOP; > - } > - > tp->t_state |= TS_SNOOP; > snp->snp_olddisc = tp->t_line; > tp->t_line = snooplinedisc;