From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 5 09:40:07 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E43411065672 for ; Sun, 5 Aug 2012 09:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1AB8FC0C for ; Sun, 5 Aug 2012 09:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q759e2jM088767 for ; Sun, 5 Aug 2012 09:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q759e2Xe088761; Sun, 5 Aug 2012 09:40:02 GMT (envelope-from gnats) Resent-Date: Sun, 5 Aug 2012 09:40:02 GMT Resent-Message-Id: <201208050940.q759e2Xe088761@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jimmy Olgeni Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29D8F106566B; Sun, 5 Aug 2012 09:34:30 +0000 (UTC) (envelope-from g.olgeni@colby.it) Received: from mail.colby.tv (93-62-141-58.ip22.fastwebnet.it [93.62.141.58]) by mx1.freebsd.org (Postfix) with ESMTP id A22328FC0A; Sun, 5 Aug 2012 09:34:28 +0000 (UTC) Received: from server.colby.local (localhost [127.0.0.1]) by server.colby.local (8.14.5/8.14.5) with ESMTP id q759VBNl028873; Sun, 5 Aug 2012 11:31:11 +0200 (CEST) (envelope-from g.olgeni@colby.it) Received: from exchange.colby.local ([192.168.1.11] helo=exchange.colby.local) with IPv4:25 by server.colby.local; 5 Aug 2012 11:31:11 +0200 Received: from backoffice.colby.local ([192.168.1.56]) by exchange.colby.local over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 5 Aug 2012 11:31:11 +0200 Received: from backoffice.colby.local (localhost [127.0.0.1]) by backoffice.colby.local (8.14.5/8.14.5) with ESMTP id q759VBK7035003; Sun, 5 Aug 2012 11:31:11 +0200 (CEST) (envelope-from olgeni@backoffice.colby.local) Received: (from olgeni@localhost) by backoffice.colby.local (8.14.5/8.14.5/Submit) id q759VBVD035002; Sun, 5 Aug 2012 11:31:11 +0200 (CEST) (envelope-from olgeni) Message-Id: <201208050931.q759VBVD035002@backoffice.colby.local> Date: Sun, 5 Aug 2012 11:31:11 +0200 (CEST) From: Jimmy Olgeni To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 X-Mailman-Approved-At: Sun, 05 Aug 2012 11:18:26 +0000 Cc: jkim@FreeBSD.org Subject: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jimmy Olgeni List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 09:40:08 -0000 >Number: 170388 >Category: amd64 >Synopsis: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 05 09:40:02 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Jimmy Olgeni >Release: FreeBSD 8.3-STABLE amd64 >Organization: >Environment: >Description: FreeBSD 8-STABLE is unable to boot in some KVM environments after r233799. ------------------------------------------------------------------------ r233799 | jkim | 2012-04-02 20:27:06 +0200 (Mon, 02 Apr 2012) | 4 lines MFC: r233702 Work around Erratum 721 for AMD Family 10h and 12h processors. ------------------------------------------------------------------------ The following panic message is shown immediately after the kernel starts: === kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff808fd8dc stack pointer = 0x28:0xffffffff80cd5440 frame pointer = 0x28:0xffffffff80cd5470 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff8064e18e at ??+0 #1 0xffffffff8061b247 at ??+0 #2 0xffffffff80912ca0 at ??+0 #3 0xffffffff80913235 at ??+0 #4 0xffffffff808faad4 at ??+0 #5 0xffffffff80904cc2 at ??+0 #6 0xffffffff801a0244 at ??+0 === When booting from the latest 8-STABLE branch the booting process just halts after the first panic line. The same problem can be observed in 9-STABLE, but I did not actually bisect all the way to the relevant commit yet. However, r233702 seems a reasonable guess. Once the system is booted by reverting r233799, the following processor information can be read: CPU: Six-Core AMD Opteron(tm) Processor 2427 (2211.49-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f80 Family = 10 Model = 8 Stepping = 0 Features=0x783fbff Features2=0x80802001 AMD Features=0xe6500800 AMD Features2=0x1f7 TSC: P-state invariant Also, using x86info: x86info v1.30. Dave Jones 2001-2011 Feedback to . Extended Family: 1 Extended Model: 0 Family: 15 Model: 8 Stepping: 0 CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion (II)/Opteron (HY-D0) Processor name string (BIOS programmed): Six-Core AMD Opteron(tm) Processor 2427 Monitor/Mwait: min/max line size 0/0, ecx bit 0 support, enumeration extension SVM: revision 1, 16 ASIDs, np, NRIPSave Address Size: 48 bits virtual, 40 bits physical running at an estimated 2.35GHz Unfortunately I have no detailed information about the QEMU configuration, but I set up a dedicated VM that I could use to test patches. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 5 14:00:06 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D4081065673 for ; Sun, 5 Aug 2012 14:00:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1A88D8FC14 for ; Sun, 5 Aug 2012 14:00:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q75E05vZ030940 for ; Sun, 5 Aug 2012 14:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q75E05A4030939; Sun, 5 Aug 2012 14:00:05 GMT (envelope-from gnats) Date: Sun, 5 Aug 2012 14:00:05 GMT Message-Id: <201208051400.q75E05A4030939@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Konstantin Belousov Cc: Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Konstantin Belousov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 14:00:06 -0000 The following reply was made to PR amd64/170388; it has been noted by GNATS. From: Konstantin Belousov To: Jimmy Olgeni Cc: FreeBSD-gnats-submit@freebsd.org, jkim@freebsd.org Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments Date: Sun, 5 Aug 2012 16:55:18 +0300 --USJBhEEH8TT+Is94 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 05, 2012 at 11:31:11AM +0200, Jimmy Olgeni wrote: >=20 > >Number: 170388 > >Category: amd64 > >Synopsis: 8-STABLE amd64 past r233799 is unable to boot in certain= KVM environments > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-amd64 > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun Aug 05 09:40:02 UTC 2012 > >Closed-Date: > >Last-Modified: > >Originator: Jimmy Olgeni > >Release: FreeBSD 8.3-STABLE amd64 > >Organization: > >Environment: > >Description: >=20 > FreeBSD 8-STABLE is unable to boot in some KVM environments after r233799. >=20 > ------------------------------------------------------------------------ > r233799 | jkim | 2012-04-02 20:27:06 +0200 (Mon, 02 Apr 2012) | 4 lines >=20 > MFC: r233702 >=20 > Work around Erratum 721 for AMD Family 10h and 12h processors. >=20 > ------------------------------------------------------------------------ >=20 > The following panic message is shown immediately after the kernel starts: >=20 > =3D=3D=3D > kernel trap 9 with interrupts disabled >=20 > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > instruction pointer =3D 0x20:0xffffffff808fd8dc > stack pointer =3D 0x28:0xffffffff80cd5440 > frame pointer =3D 0x28:0xffffffff80cd5470 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 0 () > trap number =3D 9 > panic: general protection fault > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff8064e18e at ??+0 > #1 0xffffffff8061b247 at ??+0 > #2 0xffffffff80912ca0 at ??+0 > #3 0xffffffff80913235 at ??+0 > #4 0xffffffff808faad4 at ??+0 > #5 0xffffffff80904cc2 at ??+0 > #6 0xffffffff801a0244 at ??+0 > =3D=3D=3D >=20 > When booting from the latest 8-STABLE branch the booting process > just halts after the first panic line. >=20 > The same problem can be observed in 9-STABLE, but I did not actually > bisect all the way to the relevant commit yet. However, r233702 > seems a reasonable guess. >=20 > Once the system is booted by reverting r233799, the following > processor information can be read: >=20 > CPU: Six-Core AMD Opteron(tm) Processor 2427 (2211.49-MHz K8-class CP= U) > Origin =3D "AuthenticAMD" Id =3D 0x100f80 Family =3D 10 Model = =3D 8 Stepping =3D 0 > Features=3D0x783fbff > Features2=3D0x80802001 > AMD Features=3D0xe6500800 > AMD Features2=3D0x1f7 > TSC: P-state invariant >=20 > Also, using x86info: >=20 > x86info v1.30. Dave Jones 2001-2011 > Feedback to . >=20 > Extended Family: 1 Extended Model: 0 Family: 15 Model: 8 Stepping: 0 > CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion (II)/O= pteron (HY-D0) > Processor name string (BIOS programmed): Six-Core AMD Opteron(tm) Pro= cessor 2427 >=20 > Monitor/Mwait: min/max line size 0/0, ecx bit 0 support, enumeration = extension > SVM: revision 1, 16 ASIDs, np, NRIPSave > Address Size: 48 bits virtual, 40 bits physical > running at an estimated 2.35GHz >=20 > Unfortunately I have no detailed information about the QEMU > configuration, but I set up a dedicated VM that I could use to test > patches. Try this. Comment should give enough explanation what happens there, my guess anyway. diff --git a/sys/amd64/amd64/initcpu.c b/sys/amd64/amd64/initcpu.c index 3890551..dbeaec6 100644 --- a/sys/amd64/amd64/initcpu.c +++ b/sys/amd64/amd64/initcpu.c @@ -91,11 +91,17 @@ init_amd(void) * * http://support.amd.com/us/Processor_TechDocs/41322_10h_Rev_Gd.pdf * http://support.amd.com/us/Processor_TechDocs/44739_12h_Rev_Gd.pdf + * + * Hypervisors do not provide access to the errata MSR, + * causing #GP exception on attempt to apply the errata. The + * MSR write shall be done on host and persist globally + * anyway, so do not try to do it when under virtualization. */ switch (CPUID_TO_FAMILY(cpu_id)) { case 0x10: case 0x12: - wrmsr(0xc0011029, rdmsr(0xc0011029) | 1); + if ((cpu_feature2 & CPUID2_HV) =3D=3D 0) + wrmsr(0xc0011029, rdmsr(0xc0011029) | 1); break; } } --USJBhEEH8TT+Is94 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAee0UACgkQC3+MBN1Mb4gWWACg6fxUCW+uah3gPZZxiqTEtH8j G+oAoMXjm4aBYfLr8af7cCc3PwWL/kXX =yeJJ -----END PGP SIGNATURE----- --USJBhEEH8TT+Is94-- From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 5 18:10:03 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81062106566C for ; Sun, 5 Aug 2012 18:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6068FC08 for ; Sun, 5 Aug 2012 18:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q75IA3mX061627 for ; Sun, 5 Aug 2012 18:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q75IA3aL061626; Sun, 5 Aug 2012 18:10:03 GMT (envelope-from gnats) Date: Sun, 5 Aug 2012 18:10:03 GMT Message-Id: <201208051810.q75IA3aL061626@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Jimmy Olgeni X-Mailman-Approved-At: Sun, 05 Aug 2012 21:41:41 +0000 Cc: Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jimmy Olgeni List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 18:10:03 -0000 The following reply was made to PR amd64/170388; it has been noted by GNATS. From: Jimmy Olgeni To: Konstantin Belousov Cc: jkim@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments Date: Sun, 5 Aug 2012 20:05:34 +0200 (CEST) On Sun, 5 Aug 2012, Konstantin Belousov wrote: > Try this. Comment should give enough explanation what happens there, my > guess anyway. Works great: I just booted into 8-STABLE. I'll try with 9-STABLE too - rebuilding right now. Thanks! From owner-freebsd-amd64@FreeBSD.ORG Sun Aug 5 23:30:04 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE083106564A for ; Sun, 5 Aug 2012 23:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A53738FC19 for ; Sun, 5 Aug 2012 23:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q75NU42p004708 for ; Sun, 5 Aug 2012 23:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q75NU42b004705; Sun, 5 Aug 2012 23:30:04 GMT (envelope-from gnats) Date: Sun, 5 Aug 2012 23:30:04 GMT Message-Id: <201208052330.q75NU42b004705@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: olgeni@FreeBSD.org X-Mailman-Approved-At: Sun, 05 Aug 2012 23:35:51 +0000 Cc: Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: olgeni@FreeBSD.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 23:30:05 -0000 The following reply was made to PR amd64/170388; it has been noted by GNATS. From: olgeni@FreeBSD.org To: Konstantin Belousov Cc: jkim@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments Date: Mon, 6 Aug 2012 01:27:48 +0200 (CEST) On Sun, 5 Aug 2012, Konstantin Belousov wrote: > Try this. Comment should give enough explanation what happens there, my > guess anyway. Works great on 9-STABLE too (tested on r239079). Looks like a *great* candidate for 9.1. -- jimmy From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 6 09:21:06 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A620106566C; Mon, 6 Aug 2012 09:21:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D51F8FC14; Mon, 6 Aug 2012 09:21:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q769L6W6097726; Mon, 6 Aug 2012 09:21:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q769L6at097722; Mon, 6 Aug 2012 09:21:06 GMT (envelope-from linimon) Date: Mon, 6 Aug 2012 09:21:06 GMT Message-Id: <201208060921.q769L6at097722@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, kib@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments [regression] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:21:06 -0000 Synopsis: 8-STABLE amd64 past r233799 is unable to boot in certain KVM environments [regression] Responsible-Changed-From-To: freebsd-amd64->kib Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 6 09:20:26 UTC 2012 Responsible-Changed-Why: kib has a patch and submitter notes it fixes the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=170388 From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 6 09:25:40 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C33E1106564A; Mon, 6 Aug 2012 09:25:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 95ECF8FC1B; Mon, 6 Aug 2012 09:25:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q769PeTp098182; Mon, 6 Aug 2012 09:25:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q769PeIX098178; Mon, 6 Aug 2012 09:25:40 GMT (envelope-from linimon) Date: Mon, 6 Aug 2012 09:25:40 GMT Message-Id: <201208060925.q769PeIX098178@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: ports/170357: net-mgmt/tcptrack Segmentation fault (core dumped) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 09:25:40 -0000 Synopsis: net-mgmt/tcptrack Segmentation fault (core dumped) Responsible-Changed-From-To: freebsd-amd64->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 6 09:25:24 UTC 2012 Responsible-Changed-Why: ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=170357 From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 6 11:07:03 2012 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52B41065680 for ; Mon, 6 Aug 2012 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF4498FC1D for ; Mon, 6 Aug 2012 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q76B73p7021684 for ; Mon, 6 Aug 2012 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q76B73Vj021681 for freebsd-amd64@FreeBSD.org; Mon, 6 Aug 2012 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Aug 2012 11:07:03 GMT Message-Id: <201208061107.q76B73Vj021681@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/170410 amd64 gvfs-hal-volume-monitor crashes when new media with in o amd64/170351 amd64 [kernel] [patch] amd64: 64-bit process can't always ge o amd64/170115 amd64 Serial boot broken in 9.0 o amd64/168659 amd64 [boot] FreeBSD 9 - Crash upon booting off install CD ( o amd64/167582 amd64 Compile of MySQL NDB Cluster Fails 8.2 AMD64 o amd64/167543 amd64 [kernel] Install FreeBSD can show error message with c o amd64/167393 amd64 [boot] MacBook4,1 hangs on SMP boot o amd64/166639 amd64 [boot] Syscons issue Intel D2700 o amd64/166229 amd64 [boot] Unable to install FreeBSD 9 on Acer Extensa 522 o amd64/165850 amd64 [build] 8.3-RC1 (amd64): world doesn't build with CPUT o amd64/165845 amd64 [build] Unable to build kernel on 8.2-STABLE o amd64/165351 amd64 [boot] Error while installing or booting the freeBSD O o amd64/164773 amd64 [boot] 9.0 amd64 fails to boot on HP DL145 G3 [regress o amd64/164707 amd64 FreeBSD 9 installer does not work with IBM uefi o amd64/164643 amd64 Kernel Panic at 9.0-RELEASE o amd64/164619 amd64 when logged in as root the user and group applications o amd64/164457 amd64 [install] Can't install FreeBSD 9.0 (amd64) on HP Blad o amd64/164301 amd64 [install] 9.0 - Can't install, no DHCP lease o amd64/164136 amd64 after fresh install 8.1 release or 8.2 release the har o amd64/164116 amd64 [boot] FreeBSD 9.0-RELEASE installations mediums fails o amd64/164089 amd64 FreeBSD-9.0-RELEASE-amd64-memstick.img does not boot o amd64/164073 amd64 /etc/rc warning after booting o amd64/164036 amd64 [keyboard] Moused fails on 9_0_RELENG o amd64/163736 amd64 Freebsd 8.2 with MPD5 and about 100 PPPoE clients pani o amd64/163710 amd64 setjump in userboot.so causes stack corruption o amd64/163625 amd64 Install problems of RC3 amd64 on ASRock N68 GE3 UCC o amd64/163568 amd64 hard drive naming o amd64/163285 amd64 when installing gnome2-lite not all dependent packages o amd64/163284 amd64 print manager failed to install correctly o amd64/163114 amd64 no boot on Via Nanao netbook Samsung NC20 o amd64/163092 amd64 FreeBSD 9.0-RC2 fails to boot from raid-z2 if AHCI is o amd64/163048 amd64 normal user cant mount ntfs-3g o amd64/162936 amd64 fails boot and destabilizes other OSes on FreeBSD 9 RC o amd64/162489 amd64 After some time X blanks the screen and does not respo o amd64/162314 amd64 not able to install FreeBSD-8.2-RELEASE-amd64-dvd1 as o amd64/162219 amd64 [REGRESSION] In KDE 4.7.2 cant enable OpenGL,in 4.6.5 o amd64/162170 amd64 Unable to install due to freeze at "run_interrupt_driv o amd64/161974 amd64 FreeBSD 9 new installer installs succesful, renders ma o kern/160833 amd64 Keyboard USB doesn't work o amd64/157386 amd64 [powerd] Enabling powerd(8) with default settings on I o amd64/156106 amd64 [boot] boot0 fails to start o amd64/155135 amd64 [boot] Does Not Boot On a Very Standard Hardware o amd64/154957 amd64 [boot] Install boot CD won't boot up - keeps rebooting o amd64/154629 amd64 [panic] Fatal trap 9: general protection fault while i o amd64/153935 amd64 [hang] system hangs while trying to do 'shutdown -h no o amd64/153831 amd64 [boot] CD bootloader won't on Tyan s2912G2nr o amd64/153496 amd64 [hyper-v] [install] Install on Hyper-V leaves corrupt o amd64/153372 amd64 [panic] kernel panic o amd64/153175 amd64 [amd64] Kernel Panic on only FreeBSD 8 amd64 o amd64/152874 amd64 [install] 8.1 install fails where 7.3 works due to lac o amd64/152430 amd64 [boot] HP ProLiant Microserver n36l cannot boot into i o amd64/145991 amd64 [NOTES] [patch] Add a requires line to /sys/amd64/conf o amd64/144405 amd64 [build] [patch] include /usr/obj/lib32 in cleanworld t s amd64/143173 amd64 [ata] Promise FastTrack TX4 + SATA DVD, installer can' p amd64/141413 amd64 [hang] Tyan 2881 m3289 SMDC freeze o amd64/137942 amd64 [pci] 8.0-BETA2 having problems with Asus M2N-SLI-delu o amd64/127640 amd64 [amd64] gcc(1) will not build shared libraries with -f o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c 58 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 6 08:10:02 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E264D1065686 for ; Mon, 6 Aug 2012 08:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B6AEC8FC1A for ; Mon, 6 Aug 2012 08:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q768A2Df085330 for ; Mon, 6 Aug 2012 08:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q768A2Cn085323; Mon, 6 Aug 2012 08:10:02 GMT (envelope-from gnats) Resent-Date: Mon, 6 Aug 2012 08:10:02 GMT Resent-Message-Id: <201208060810.q768A2Cn085323@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Giacomo Strangolino Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B87B1065679 for ; Mon, 6 Aug 2012 08:00:50 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF0B8FC24 for ; Mon, 6 Aug 2012 08:00:50 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q7680onA020266 for ; Mon, 6 Aug 2012 08:00:50 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q7680ol8020265; Mon, 6 Aug 2012 08:00:50 GMT (envelope-from nobody) Message-Id: <201208060800.q7680ol8020265@red.freebsd.org> Date: Mon, 6 Aug 2012 08:00:50 GMT From: Giacomo Strangolino To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Mon, 06 Aug 2012 11:13:17 +0000 Cc: Subject: amd64/170410: gvfs-hal-volume-monitor crashes when new media with invalid encoding characters are plugged in. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 08:10:03 -0000 >Number: 170410 >Category: amd64 >Synopsis: gvfs-hal-volume-monitor crashes when new media with invalid encoding characters are plugged in. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Aug 06 08:10:02 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Giacomo Strangolino >Release: 9.0 >Organization: Elettra Sincrotrone Trieste >Environment: FreeBSD woody 9.0-RELEASE FreeBSD 9.0-RELEASE >Description: - Plug in a media (USB Stick or CDROM) where a name of file or folder contains characters with invalid encoding. - /usr/local/libexec/gvfs-hal-volume-monitor immediately crashes. Backtrace: [giacomo@woody ~]$ gdb /usr/local/libexec/gvfs-hal-volume-monitor gvfs-hal-volume-mon.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or 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. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... warning: core file may not match specified executable file. Core was generated by `gvfs-hal-volume-mon'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libhal.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libhal.so.1 Reading symbols from /usr/local/lib/libgvfscommon.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgvfscommon.so.0 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libgio-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libintl.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libpcre.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.1 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/gio/modules/libgvfsdbus.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libgvfsdbus.so Reading symbols from /usr/local/lib/gio/modules/libgiofam.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libgiofam.so Reading symbols from /usr/local/lib/libfam.so.0...done. Loaded symbols for /usr/local/lib/libfam.so.0 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000802bf9ad7 in strlen () from /lib/libc.so.7 [New Thread 80300b400 (LWP 145853/gvfs-hal-volume-mon)] [New Thread 80300d000 (LWP 146372/gvfs-hal-volume-mon)] [New Thread 80300cc00 (LWP 146371/gvfs-hal-volume-mon)] [New Thread 803007400 (LWP 136463/gvfs-hal-volume-mon)] (gdb) bt #0 0x0000000802bf9ad7 in strlen () from /lib/libc.so.7 #1 0x0000000801ad7bfc in g_utf8_collate_key () from /usr/local/lib/libglib-2.0.so.0 #2 0x0000000000000000 in ?? () #3 0x0000000000000000 in ?? () #4 0x0000000000000000 in ?? () #5 0x00000008030460a8 in ?? () #6 0x0000000803d3c6a0 in ?? () #7 0x0000000803180250 in ?? () #8 0x0000000000000000 in ?? () #9 0x0000000000000000 in ?? () #10 0x0000000000000000 in ?? () #11 0x0000000800f0dbe5 in g_cancellable_source_new () from /usr/local/lib/libgio-2.0.so.0 #12 0x0000000803da8240 in ?? () #13 0x000000080317cd20 in ?? () #14 0x000000080317cd20 in ?? () #15 0x000000080313a8c0 in ?? () #16 0x0000000803d35180 in ?? () #17 0x0000000803180250 in ?? () #18 0x0000000803d35180 in ?? () #19 0x0000000803046e78 in ?? () #20 0x000000080311dd20 in ?? () #21 0x000000080309b620 in ?? () #22 0x0000000800fab500 in .rodata () from /usr/local/lib/libgio-2.0.so.0 #23 0x0000000800f0ddd5 in g_cancellable_source_new () from /usr/local/lib/libgio-2.0.so.0 #24 0x0000000800f0f8e7 in g_content_type_guess_for_tree () from /usr/local/lib/libgio-2.0.so.0 #25 0x000000000040c326 in ?? () #26 0x000000000040e764 in ?? () #27 0x000000000040ed4c in ?? () #28 0x000000080142178e in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #29 0x0000000000000000 in ?? () #30 0x000000080142170f in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 .. et cetera... Gnome is configured through PolicyKit.conf in order to auto mount pluggable media. gvfs info: PORTNAME= gvfs PORTVERSION= 1.6.6 PORTREVISION= 3 >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 8 18:50:01 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 940331065672 for ; Wed, 8 Aug 2012 18:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1FC8FC1E for ; Wed, 8 Aug 2012 18:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q78Io1F6012487 for ; Wed, 8 Aug 2012 18:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q78Io1FX012486; Wed, 8 Aug 2012 18:50:01 GMT (envelope-from gnats) Resent-Date: Wed, 8 Aug 2012 18:50:01 GMT Resent-Message-Id: <201208081850.q78Io1FX012486@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Per olof Ljungmark Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E572C106564A for ; Wed, 8 Aug 2012 18:46:39 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id B82F08FC12 for ; Wed, 8 Aug 2012 18:46:39 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q78Ikdb4056900 for ; Wed, 8 Aug 2012 18:46:39 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q78IkdKN056899; Wed, 8 Aug 2012 18:46:39 GMT (envelope-from nobody) Message-Id: <201208081846.q78IkdKN056899@red.freebsd.org> Date: Wed, 8 Aug 2012 18:46:39 GMT From: Per olof Ljungmark To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: amd64/170487: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 18:50:01 -0000 >Number: 170487 >Category: amd64 >Synopsis: Thinkpad X61s cannot boot 9.1-BETA1 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 08 18:50:01 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Per olof Ljungmark >Release: 9.1-BETA1 >Organization: >Environment: 9.1-BETA1 amd64 >Description: Thinkpad X61s is unable to boot 9.1-BETA1. A verbose boot, last line is acpi_acad: acline initialization done, tried 1 times Issuing a 'set debug.acpi.disabled="hostres"' does not help. Disabling ACPI altogether does not help either, boot stops at "No usable eventtimer found". >How-To-Repeat: Try to install 9.1-BETA on a Thinkpad X61s >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 8 22:10:09 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 559921065672 for ; Wed, 8 Aug 2012 22:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AEEF48FC1C for ; Wed, 8 Aug 2012 22:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q78MA3Zb036203 for ; Wed, 8 Aug 2012 22:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q78MA3kS036202; Wed, 8 Aug 2012 22:10:03 GMT (envelope-from gnats) Date: Wed, 8 Aug 2012 22:10:03 GMT Message-Id: <201208082210.q78MA3kS036202@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Konstantin Belousov X-Mailman-Approved-At: Wed, 08 Aug 2012 22:20:33 +0000 Cc: Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get unlimited rlimit X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Konstantin Belousov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 22:10:09 -0000 The following reply was made to PR amd64/170351; it has been noted by GNATS. From: Konstantin Belousov To: Ming Qiao Cc: Erin MacNeil , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get unlimited rlimit Date: Thu, 9 Aug 2012 01:06:31 +0300 --V8ijD2GsuVnOuiV5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Do not strip public lists from the discussion. There is nothing private. On Tue, Aug 07, 2012 at 05:52:07PM -0400, Ming Qiao wrote: > Hi Konstantin, >=20 > Thanks for your quick response. Actually I'm not very clear about > the second approach you mentioned. Some questions here: 1) Could you > please elaborate the idea of "tracking rlimits set to ABI infinity"? > If I understand correctly, you are referring to a model where a > process can have it rlimit set multiple times by different ABI? But > what does it mean exactly? Could you give a simple example here? 2) > What do you mean by "per-struct rlimit"? Do you mean each memory > segment as a struct? such as datasize, stacksize, etc. I mean that in addition to the existing array of pl_rlimit in struct plimit, you also create an bitmap array of the same size. Set bit in this new array would indicate that corresponding limit was set (either implicit, or explicitely by usermode) to infinity. The bit has its meaning regardless of the actual numeric value written into the pl_rlimit, either by syscall or by sv_fixup. Then, 64bit sysent should also grow sv_fixup for resource limits, and set it accordingly for host ABI if array indicates that resource is logically 'infinite'. For completeness, I should note that bit is cleared if syscall sets the resource to non-infinite value. Per-struct rlimit means that there is a bit for each resource. Is it clear now ? > >=20 > Thanks, > Ming >=20 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com]=20 > Sent: Friday, August 03, 2012 1:39 PM > To: Ming Qiao > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get= unlimited rlimit >=20 > On Fri, Aug 03, 2012 at 03:35:20PM +0000, Ming Qiao wrote: > >=20 > > >Number: 170351 > > >Category: amd64 > > >Synopsis: [patch] amd64: 64-bit process can't always get unlimit= ed rlimit > > >Confidential: no > > >Severity: non-critical > > >Priority: low > > >Responsible: freebsd-amd64 > > >State: open > > >Quarter: =20 > > >Keywords: =20 > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Fri Aug 03 15:40:08 UTC 2012 > > >Closed-Date: > > >Last-Modified: > > >Originator: Ming Qiao > > >Release: FreeBSD 9.0-RC2 > > >Organization: > > Juniper Networks > > >Environment: > > FreeBSD neys 9.0-RC2 FreeBSD 9.0-RC2 #0: Thu Jul 26 01:27:46 UTC 2012= =20 > > root@neys:/usr/obj/usr/src/sys/GENERIC amd64 > > >Description: > > On the amd64 platform, if a 32-bit process ever manually set its=20 > > rlimit, none of its 64-bit child or offspring will be able to get the= =20 > > full 64-bit rlimit anymore, even if they explicitly set the limit to un= limited. > >=20 > > Note that for the sake of simplicity, only datasize limit is referred= =20 > > in this report. But the same logic applies to all other memory segment= =20 > > (i.e. stacksize, etc.). > >=20 > > Take the following scenario as an example: > > 1) Let's say we have a 32-bit process p1 whose hard limit is set to=20 > > 500MB by calling setrlimit(). > > 2) p1 then exec another 32-bit process p2. > > 3) p2 set its hard limit to unlimited by calling setrlimit(). > > 4) p2 exec a 64-bit process p3. > > 5) check the hard limit of p3, we can see that it only has 3GB (value= =20 > > of > > ia32_maxdsiz) instead of 32GB which is the global kernel limit (value= =20 > > of > > maxdsiz) for a 64-bit process. > >=20 > > The root cause is that on step 3, p2 didn't actually set its limit to= =20 > > the correct value when calling setrlimit(). Instead the limit is set=20 > > to ia32_maxdsiz since ia32_fixlimit() is called in kern_proc_setrlimit(= ). > > >How-To-Repeat: > > There are 3 test programs attached in this report: 32_p1.c, 32_p2.c,=20 > > and 64_p3.c. They can be used to reproduce the problem. > >=20 > > 1) Compile 32_p1.c and 32_p2.c into 32-bit binaries. Compile 64_p3.c=20 > > into 64-bit binary. > > 2) Put all 3 binaries into the same directory on a machine running=20 > > FreeBSD > > amd64 version. > > 3) Run 32_p1 which will exec 32_p2 and 64_p3. The output of 64_p3 will= =20 > > show its limit is capped at ia32_maxdsiz. > > >Fix: > > The proposed fix is to change kern_proc_setrlimit() so that=20 > > sv_fixlimit() will not be called if the caller wants to set the new lim= it to RLIM_INFINITY. > > Please refer to the attached diff file for the proposed fix. > The 'fix' is wrong and does not address the issue. > Instead, it uses some arbitrary properties of the scenario you considered= and adapts kernel code to suit your scenario. Your deny the correction of = the infinity limit, I do not see how it can be right. >=20 > The problem you described is architectural. By design, Unix resource limi= ts cannot be increased after they were decreased, except by root. > In your scenario, the limits were decreased by mere fact of running the 3= 2bit process which have lower 'infinity' limits then 64bit processes. >=20 > That said, I see two possible solutions. >=20 > First is to manually set compat.ia32.max* sysctls to 0. Then you get desi= red behaviour for 64bit processes execed from 32bit, it seems. > It does not require code change. Since you are fine with denying fix for = infinity, this setting gives the same effect as the patch. >=20 > Second approach (which is essentially a correction to your approach from = fix.diff) is to track the fact that corresponding rlimits are set to 'ABI i= nfinity', in some per-struct rlimit flag. Then, get/setrlimit should first = test the 'ABI infinity' flag and behave as if rlimit is set to infinity for= current bitness even if the actual value of rlimit is not infinity. Flag i= s set when rlimit is set to infinity by current ABI. >=20 > The second approach would provide 'correct' fix, but it is not trivial am= ount of work for very rare situation (execing 64bit process from 32bit), an= d current behaviour of inheriting 32bit limits may be argued as right. > If you want, feel free to develop such patch, I will review and commit it= , but I do not want to spend efforts on developing it myself ATM. --V8ijD2GsuVnOuiV5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAi4ucACgkQC3+MBN1Mb4grKACg01g2AphuVQdC389JCrfSck+x 5xIAoMuYfuQ4aKvCgcKShvGM4b2ftkVn =q/lG -----END PGP SIGNATURE----- --V8ijD2GsuVnOuiV5-- From owner-freebsd-amd64@FreeBSD.ORG Thu Aug 9 20:20:03 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99C711065672 for ; Thu, 9 Aug 2012 20:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4D78FC12 for ; Thu, 9 Aug 2012 20:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q79KK3m1028433 for ; Thu, 9 Aug 2012 20:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q79KK3wg028432; Thu, 9 Aug 2012 20:20:03 GMT (envelope-from gnats) Date: Thu, 9 Aug 2012 20:20:03 GMT Message-Id: <201208092020.q79KK3wg028432@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Ming Qiao X-Mailman-Approved-At: Thu, 09 Aug 2012 22:49:07 +0000 Cc: Subject: RE: amd64/170351: [patch] amd64: 64-bit process can't always get unlimited rlimit X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ming Qiao List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:20:03 -0000 The following reply was made to PR amd64/170351; it has been noted by GNATS. From: Ming Qiao To: Konstantin Belousov Cc: Erin MacNeil , "freebsd-gnats-submit@freebsd.org" Subject: RE: amd64/170351: [patch] amd64: 64-bit process can't always get unlimited rlimit Date: Thu, 9 Aug 2012 16:16:38 -0400 Thanks for the explanation. I'll prepare a fix and send it to you for revie= w when it's ready. ...Ming -----Original Message----- From: Konstantin Belousov [mailto:konstantin.belousov@zoral.com.ua]=20 Sent: Wednesday, August 08, 2012 6:07 PM To: Ming Qiao Cc: Erin MacNeil; freebsd-gnats-submit@freebsd.org Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get u= nlimited rlimit Do not strip public lists from the discussion. There is nothing private. On Tue, Aug 07, 2012 at 05:52:07PM -0400, Ming Qiao wrote: > Hi Konstantin, >=20 > Thanks for your quick response. Actually I'm not very clear about the=20 > second approach you mentioned. Some questions here: 1) Could you=20 > please elaborate the idea of "tracking rlimits set to ABI infinity"? > If I understand correctly, you are referring to a model where a=20 > process can have it rlimit set multiple times by different ABI? But=20 > what does it mean exactly? Could you give a simple example here? 2)=20 > What do you mean by "per-struct rlimit"? Do you mean each memory=20 > segment as a struct? such as datasize, stacksize, etc. I mean that in addition to the existing array of pl_rlimit in struct plimit= , you also create an bitmap array of the same size. Set bit in this new arr= ay would indicate that corresponding limit was set (either implicit, or exp= licitely by usermode) to infinity. The bit has its meaning regardless of th= e actual numeric value written into the pl_rlimit, either by syscall or by = sv_fixup. Then, 64bit sysent should also grow sv_fixup for resource limits, and set i= t accordingly for host ABI if array indicates that resource is logically 'i= nfinite'. For completeness, I should note that bit is cleared if syscall sets the res= ource to non-infinite value. Per-struct rlimit means that there is a bit fo= r each resource. Is it clear now ? > >=20 > Thanks, > Ming >=20 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Friday, August 03, 2012 1:39 PM > To: Ming Qiao > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always=20 > get unlimited rlimit >=20 > On Fri, Aug 03, 2012 at 03:35:20PM +0000, Ming Qiao wrote: > >=20 > > >Number: 170351 > > >Category: amd64 > > >Synopsis: [patch] amd64: 64-bit process can't always get unlimit= ed rlimit > > >Confidential: no > > >Severity: non-critical > > >Priority: low > > >Responsible: freebsd-amd64 > > >State: open > > >Quarter: =20 > > >Keywords: =20 > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Fri Aug 03 15:40:08 UTC 2012 > > >Closed-Date: > > >Last-Modified: > > >Originator: Ming Qiao > > >Release: FreeBSD 9.0-RC2 > > >Organization: > > Juniper Networks > > >Environment: > > FreeBSD neys 9.0-RC2 FreeBSD 9.0-RC2 #0: Thu Jul 26 01:27:46 UTC=20 > > 2012 root@neys:/usr/obj/usr/src/sys/GENERIC amd64 > > >Description: > > On the amd64 platform, if a 32-bit process ever manually set its=20 > > rlimit, none of its 64-bit child or offspring will be able to get=20 > > the full 64-bit rlimit anymore, even if they explicitly set the limit t= o unlimited. > >=20 > > Note that for the sake of simplicity, only datasize limit is=20 > > referred in this report. But the same logic applies to all other=20 > > memory segment (i.e. stacksize, etc.). > >=20 > > Take the following scenario as an example: > > 1) Let's say we have a 32-bit process p1 whose hard limit is set to=20 > > 500MB by calling setrlimit(). > > 2) p1 then exec another 32-bit process p2. > > 3) p2 set its hard limit to unlimited by calling setrlimit(). > > 4) p2 exec a 64-bit process p3. > > 5) check the hard limit of p3, we can see that it only has 3GB=20 > > (value of > > ia32_maxdsiz) instead of 32GB which is the global kernel limit=20 > > (value of > > maxdsiz) for a 64-bit process. > >=20 > > The root cause is that on step 3, p2 didn't actually set its limit=20 > > to the correct value when calling setrlimit(). Instead the limit is=20 > > set to ia32_maxdsiz since ia32_fixlimit() is called in kern_proc_setrli= mit(). > > >How-To-Repeat: > > There are 3 test programs attached in this report: 32_p1.c, 32_p2.c,=20 > > and 64_p3.c. They can be used to reproduce the problem. > >=20 > > 1) Compile 32_p1.c and 32_p2.c into 32-bit binaries. Compile 64_p3.c=20 > > into 64-bit binary. > > 2) Put all 3 binaries into the same directory on a machine running=20 > > FreeBSD > > amd64 version. > > 3) Run 32_p1 which will exec 32_p2 and 64_p3. The output of 64_p3=20 > > will show its limit is capped at ia32_maxdsiz. > > >Fix: > > The proposed fix is to change kern_proc_setrlimit() so that > > sv_fixlimit() will not be called if the caller wants to set the new lim= it to RLIM_INFINITY. > > Please refer to the attached diff file for the proposed fix. > The 'fix' is wrong and does not address the issue. > Instead, it uses some arbitrary properties of the scenario you considered= and adapts kernel code to suit your scenario. Your deny the correction of = the infinity limit, I do not see how it can be right. >=20 > The problem you described is architectural. By design, Unix resource limi= ts cannot be increased after they were decreased, except by root. > In your scenario, the limits were decreased by mere fact of running the 3= 2bit process which have lower 'infinity' limits then 64bit processes. >=20 > That said, I see two possible solutions. >=20 > First is to manually set compat.ia32.max* sysctls to 0. Then you get desi= red behaviour for 64bit processes execed from 32bit, it seems. > It does not require code change. Since you are fine with denying fix for = infinity, this setting gives the same effect as the patch. >=20 > Second approach (which is essentially a correction to your approach from = fix.diff) is to track the fact that corresponding rlimits are set to 'ABI i= nfinity', in some per-struct rlimit flag. Then, get/setrlimit should first = test the 'ABI infinity' flag and behave as if rlimit is set to infinity for= current bitness even if the actual value of rlimit is not infinity. Flag i= s set when rlimit is set to infinity by current ABI. >=20 > The second approach would provide 'correct' fix, but it is not trivial am= ount of work for very rare situation (execing 64bit process from 32bit), an= d current behaviour of inheriting 32bit limits may be argued as right. > If you want, feel free to develop such patch, I will review and commit it= , but I do not want to spend efforts on developing it myself ATM.