Date: Fri, 2 Apr 2010 08:46:29 +0300 From: Oleg Lomaka <oleg.lomaka@gmail.com> To: pluknet <pluknet@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 Message-ID: <67FC0BD4-E06F-4DA1-AED3-B0D3B3D5A640@gmail.com> In-Reply-To: <g2qa31046fc1004011852p3686b01ct256072bf22fa4013@mail.gmail.com> References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> <g2qa31046fc1004011852p3686b01ct256072bf22fa4013@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-3--177786261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 2, 2010, at 4:52 AM, pluknet wrote: > On 1 April 2010 22:18, Oleg Lomaka <oleg.lomaka@gmail.com> wrote: >>=20 >>=20 >> I have a kernel panic when connect to postgresql8.4 server installed = in one of jails from another jail. It's 100% reproducible. >> Also I have tried to connect from host machine to jailed pg server. = That way it works fine without crash. >>=20 >> Server configuration uses geli and zfs. Four disks encrypted using = geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli = providers. All jails located at this raidz2 pool. >>=20 >> Also I use ezjail for jails management. And it uses NFS to mount = directories with base system. >>=20 >> atal double fault >> rip =3D 0xffffffff8063510a >> rsp =3D 0xffffff80eaec5f50 >> rbp =3D 0xffffff80eaec6040 >> cpuid =3D 1; apic id =3D 02 >> panic: double fault >> cpuid =3D 1 >> Uptime: 7m11s >> Physical memory: 8169 MB >>=20 >> uname -a >> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 = r206031: Thu Apr 1 13:43:57 EEST 2010 = root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 >>=20 >> Link to dmesg.boot: >> = http://docs.google.com/leaf?id=3D0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTli= ZDctZjU3N2YwNmMxNjZl&hl=3Den >>=20 >> Link to kernel core backtrace: >> = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&h= l=3Den >=20 > Looking at backtrace, I wonder whether tp->t_maxseg changes in > tcp_mtudisc() at all. > You should be able to extract its value on each 2*n frame in that big > recursive call. You are right, pt->t_maxseg doesn't change (kgdb) frame 9 #9 0xffffffff807097e8 in tcp_mtudisc (inp=3D0xffffff00193c53f0, = errno=3DVariable "errno" is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp->t_maxseg $1 =3D 14336 (kgdb) frame 11 #11 0xffffffff807097e8 in tcp_mtudisc (inp=3D0xffffff00193c53f0, = errno=3DVariable "errno" is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp->t_maxseg $2 =3D 14336 ... (full log at = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfNGQ4cWpia2dz&h= l=3Den ) (kgdb) frame 81 #81 0xffffffff807097e8 in tcp_mtudisc (inp=3D0xffffff00193c53f0, = errno=3DVariable "errno" is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp->t_maxseg $37 =3D 14336 (kgdb)=20= --Apple-Mail-3--177786261--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67FC0BD4-E06F-4DA1-AED3-B0D3B3D5A640>