Date: Sun, 25 Nov 2007 22:30:15 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Rako <rako29@gmail.com> Cc: freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: snp panic [Was: Re: panic with tcpdrop] Message-ID: <20071125203015.GF78396@deviant.kiev.zoral.com.ua> In-Reply-To: <4749B2CC.7020300@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071125203015.GF78396>