From owner-freebsd-stable@freebsd.org Sun Mar 11 06:07:57 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 147CBF2F849 for ; Sun, 11 Mar 2018 06:07:57 +0000 (UTC) (envelope-from Andreas.Nagy@frequentis.com) Received: from mail2.frequentis.com (mail2.frequentis.com [195.20.158.51]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "spamquarantine.frequentis.frq", Issuer "Frequentis Enterprise Issuing CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FF327A27E for ; Sun, 11 Mar 2018 06:07:55 +0000 (UTC) (envelope-from Andreas.Nagy@frequentis.com) X-IronPort-AV: E=Sophos;i="5.47,454,1515452400"; d="scan'208,217";a="2453848" Received: from vie191nt.frequentis.frq ([172.16.1.191]) by mail2.frequentis.com with ESMTP; 11 Mar 2018 07:07:47 +0100 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie191nt.frequentis.frq ([172.16.1.191]) with mapi id 14.03.0382.000; Sun, 11 Mar 2018 07:07:47 +0100 From: NAGY Andreas To: Rick Macklem , "'freebsd-stable@freebsd.org'" Subject: =?iso-8859-1?Q?Re:_NFS_4.1_RECLAIM=5FCOMPLETE_FS=A0failed_error_in_combin?= =?iso-8859-1?Q?ation_with_ESXi_client?= Thread-Topic: =?iso-8859-1?Q?NFS_4.1_RECLAIM=5FCOMPLETE_FS=A0failed_error_in_combinatio?= =?iso-8859-1?Q?n_with_ESXi_client?= Thread-Index: AdOx8zAe5+TceuOWQkax+IhJZhNDgQAnzopHABn27/AAIBzCQgAP8SUgAAmzYWAADy6jKgAZTvpAABQ08bcAKLRnLwArPwd4AAPK4ZAAFJa1tQAZS9wAABCp2AIAIYll8AAB3b2wABNx/+gAGe9tgAATPsrUABB6NWI= Date: Sun, 11 Mar 2018 06:07:46 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 06:07:57 -0000 Thanks! Please keep me updated if you find put more or when a updated versi= on is available. As I now know it is working, I will start tomorrow to build up a testsystem= with 3 NFS servers (two of them in a ha with CARP and HAST) and several ES= Xi hosts which will all access there NFS datastores over 4 uplinks with NIC= s on different subnets. It should always be possible to do there some testing. andi ________________________________ Von: Rick Macklem Gesendet: 10.03.2018 11:20 nachm. An: NAGY Andreas; 'freebsd-stable@freebsd.org' Betreff: Re: NFS 4.1 RECLAIM_COMPLETE FS failed error in combination with E= SXi client NAGY Andreas wrote: >Thanks, the not issuing delegation warnings disappeared with this patch. > >But now there are some new warnings I haven't seen so far: >2018-03-10T13:01:39.441Z cpu8:68046)WARNING: NFS41: NFS41FSOpGetObject:214= 8: Failed to >get object 0x43910e71b386 [36 c6b10167 9b157f95 5aa100fb 8ffc= f2c1 c 2 9f22ad6d 0 0 0 0 0]: >Stale file handle I doubt these would be related to the patch. A stale FH means that the clie= nt tried to access a file via its FH after it was removed. (Normally this is a client b= ug, but hopefully not one that will cause grief.) >These only appear several times after a the NFS share is mounted or remoun= ted after a >connection loss. >Everything works fine, but haven't seen them till I applied the last patch= . > >andi Ok. Thanks for testing all of these patches. I will probably get cleaned up= versions of them committed in April. The main outstanding issue is the Readdir one about directory changing too = much. Hopefully I can find out something about it via email. Have fun with it, rick From owner-freebsd-stable@freebsd.org Sun Mar 11 21:12:57 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 370BBF4FD94 for ; Sun, 11 Mar 2018 21:12:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670074.outbound.protection.outlook.com [40.107.67.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A21C17FCF3 for ; Sun, 11 Mar 2018 21:12:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM (52.132.66.153) by YQBSPR01MB09.CANPRD01.PROD.OUTLOOK.COM (52.132.72.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.548.14; Sun, 11 Mar 2018 21:12:54 +0000 Received: from YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM ([fe80::3531:c817:d6f:9b93]) by YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM ([fe80::3531:c817:d6f:9b93%13]) with mapi id 15.20.0567.018; Sun, 11 Mar 2018 21:12:54 +0000 From: Rick Macklem To: NAGY Andreas , "'freebsd-stable@freebsd.org'" Subject: =?iso-8859-1?Q?Re:_NFS_4.1_RECLAIM=5FCOMPLETE_FS=A0failed_error_in_combin?= =?iso-8859-1?Q?ation_with_ESXi_client?= Thread-Topic: =?iso-8859-1?Q?NFS_4.1_RECLAIM=5FCOMPLETE_FS=A0failed_error_in_combinatio?= =?iso-8859-1?Q?n_with_ESXi_client?= Thread-Index: AdOx8zAe5+TceuOWQkax+IhJZhNDgQAnzopHABn27/AAIBzCQgAP8SUgAAmzYWAADy6jKgAZTvpAABQ08bcAKLRnLwArPwd4AAPK4ZAAFJa1tQAZS9wAABCp2AIAIYll8AAB3b2wABNx/+gAGe9tgAATPsrUABB6NWIAH36zTg== Date: Sun, 11 Mar 2018 21:12:54 +0000 Message-ID: References: , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBSPR01MB09; 6:LvgirvP/Giw5ocWoqqHLitebXO5CH5lVIWhTFAX8ybxUPbH5jYMD0LdaUsu3t3Yogb4Z6sEluztLLx0w3xmMWgoSTRM5dWerr4ENVBMrARBDyqfIo1ORsvO+RW4uUglejahHV4DWEGTXhlsV8682ztLl6yY70eimgo544xK/+iJF3rHznfLz9tZSP53IP15rQD0/Atm/FuIkCXA+HkGWV1O/CHl0TrAVzyDEqyh8XnBAgJ9m0lAfIc88hHHFn4xkaHWk9B5ngjZKjHoYGov1jFjGdvhbbulEZdBwfeg+xktS2yv60JyAI00oLpjzgAmJ3orO98mKFiwxX9D4aZzp34UzsyUCqYi27zFBnRhg1G2gsHpCTl32B3+RUwjhjynD; 5:Oggc+ahOhqcDAkgiOfaZbNfrE0PwgWh0cU2D0P5D1qHhGZxac+8557oHliVSoZboZbMSQahbq6Gy/+ZtLJK3Ri3fcg1osnbTRzncIFDVkL1NCKh4veAFDaEi19V/VIO0OQqIrbMJC5pY2217hSQJHXmRRE9HfpNLyHBaQDpvhLg=; 24:5jYoyFdfjKzkGUiqcj0eghG7IY6mzWsbXF/RVNdu5s4qvNAmfYKY6TMg9uXyJuRbCBl6vebi9d1o6I4pqBVss3PrlhODsDlXxCcfu18i09g=; 7:XjNTv0JwSmKAbx16K30C0yvJaGUub79+LCEy/lcKjJah3zX0kA/Ow/1xpISHCrvrvMlcpiE7LTlP1pOvso6Z3SL3fdlJvS8ah04jC74JxY+13HCK5RBnQf2Krawme2HYugLvhRag3YyPD6j6Tjf/W2NH316vqCTji8seAgNxRqyep8q+S2G1otSnuVXum2lUB6ipnqNNyd2NwH7IuH8ypbnhCtBM8GOsUwwWozPoQneRAifiIbAUJHjK8BpXneiQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1d902065-d86f-4295-5d48-08d58794db73 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:YQBSPR01MB09; x-ms-traffictypediagnostic: YQBSPR01MB09: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(6041310)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:YQBSPR01MB09; BCL:0; PCL:0; RULEID:; SRVR:YQBSPR01MB09; x-forefront-prvs: 0608DEDB67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39380400002)(39850400004)(366004)(396003)(51944003)(189003)(199004)(74316002)(97736004)(74482002)(110136005)(81166006)(81156014)(5660300001)(316002)(186003)(786003)(68736007)(14454004)(8936002)(478600001)(102836004)(2950100002)(229853002)(33656002)(106356001)(305945005)(25786009)(2906002)(5250100002)(105586002)(93886005)(9686003)(55016002)(53936002)(6506007)(6246003)(76176011)(86362001)(7696005)(2900100001)(6436002)(3660700001)(59450400001)(3280700002)(99286004)(26005)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBSPR01MB09; H:YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: ELHu02r/m0M/JiE/5lftiYzmObo5w8HHzLn1G4zGnFfr5NVrFOVZ1Nf/7ga7IMeomYOnyW2X/dmVlHEB4RsVip46NDxza6453U3mae0Sc3Jhenbj2Gx+71lYUXD4mLKcxWgI8HBcLUcPVM0dKqx7D282HAhHekRZwvATzmYwDWWSwr4rSqCT61QpdiNV+0XKDjT4JwKCMzTSt0xDuhOPMMv7x0iipnfeMQx3Joen/tAPV9UFJ55hzaLM9Av/2y6uvkUAuHigArW3t0/xqwucnTah14g+x742pjmhL0iic8A2YsgjU/nC8Sim6TzcvXH5PjUtiTdFB8t3Hfki/720UQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 1d902065-d86f-4295-5d48-08d58794db73 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2018 21:12:54.8692 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBSPR01MB09 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 21:12:57 -0000 NAGY Andreas wrote: >Thanks! Please keep me updated if you find put more or when a updated vers= ion is available. Will try to remember to do so. >As I now know it is working, I will start tomorrow to build up a testsyste= m with 3 NFS servers >(two of them in a ha with CARP and HAST) and several = ESXi hosts which will all access there >NFS datastores over 4 uplinks with = NICs on different subnets. >It should always be possible to do there some testing. Have fun. That's way beyond anything I do for NFS testing. Btw, unless you don't want me to, I will list you as "Tested by:" on the co= mmits. (If you don't want me to do this, just email.) Good luck with the testing, rick From owner-freebsd-stable@freebsd.org Mon Mar 12 17:21:10 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF2B3F2D6A3 for ; Mon, 12 Mar 2018 17:21:10 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2C786F6B; Mon, 12 Mar 2018 17:21:10 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6]) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1evR8F-00042h-Kv; Mon, 12 Mar 2018 17:21:07 +0000 Subject: Re: zfs problems after rebuilding system [SOLVED] To: Ian Lepore , freebsd-stable@freebsd.org References: <21c64a2d-b9f9-24c8-88ec-ff1210891f60@zyxst.net> <65372449-53f1-8002-981a-e20f4a592e26@zyxst.net> <5CFC89E9-57BE-4CB7-9C55-0D3CCF1E8D3D@FreeBSD.org> <20180303234236.M3811@besplex.bde.org> <9b3cd942-347c-44a2-60d6-0b3c4a45552f@ingresso.co.uk> <1520723109.84937.136.camel@freebsd.org> <84146241-12d3-8333-0687-c2377838f175@ingresso.co.uk> <1520723722.84937.139.camel@freebsd.org> <217437b9-9879-8919-966a-45cf5eb58d33@ingresso.co.uk> <1520725685.84937.144.camel@freebsd.org> From: Pete French Message-ID: <831aa29b-6464-eb6c-e9c9-058963756ec8@ingresso.co.uk> Date: Mon, 12 Mar 2018 17:21:07 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1520725685.84937.144.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 17:21:10 -0000 On 10/03/2018 23:48, Ian Lepore wrote: > I based my fix heavily on that patch from the PR, but I rewrote it > enough that I might've made any number of mistakes, so it needs fresh > testing.  The main change I made was to make it a lot less noisy while > waiting (it only mentions the wait once, unless bootverbose is set, in > which case it's once per second).  I also removed the logic that > limited the retries to nfs and zfs, because I think we can remove all > the old code related to waiting that only worked for ufs and let this > new retry be the way it waits for all filesystems.  But that's a bigger > change we can do separately; I didn't want to hold up this fix any > longer. TThansk for the patch, its is very much appercaited! I applied this earlier today, and have been continuously rebooting the machine in Azure ever since (every ten minutes). This has worked flawlessly, so I am very happy that this fixes the issue for me. I am going to leave it running though, just to see if anything happens. I havent examined dmesg, but I thould be able to see the output from the patch there to verify that its waiting, yes ? cheers, -pete. From owner-freebsd-stable@freebsd.org Mon Mar 12 17:37:48 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C58ABF2F02D for ; Mon, 12 Mar 2018 17:37:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F1A487D19 for ; Mon, 12 Mar 2018 17:37:46 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f2239e46-261b-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id f2239e46-261b-11e8-b951-f99fef315fd9; Mon, 12 Mar 2018 17:36:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2CHbggJ016811; Mon, 12 Mar 2018 11:37:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1520876261.84937.222.camel@freebsd.org> Subject: Re: zfs problems after rebuilding system [SOLVED] From: Ian Lepore To: Pete French , freebsd-stable@freebsd.org Date: Mon, 12 Mar 2018 11:37:41 -0600 In-Reply-To: <831aa29b-6464-eb6c-e9c9-058963756ec8@ingresso.co.uk> References: <21c64a2d-b9f9-24c8-88ec-ff1210891f60@zyxst.net> <65372449-53f1-8002-981a-e20f4a592e26@zyxst.net> <5CFC89E9-57BE-4CB7-9C55-0D3CCF1E8D3D@FreeBSD.org> <20180303234236.M3811@besplex.bde.org> <9b3cd942-347c-44a2-60d6-0b3c4a45552f@ingresso.co.uk> <1520723109.84937.136.camel@freebsd.org> <84146241-12d3-8333-0687-c2377838f175@ingresso.co.uk> <1520723722.84937.139.camel@freebsd.org> <217437b9-9879-8919-966a-45cf5eb58d33@ingresso.co.uk> <1520725685.84937.144.camel@freebsd.org> <831aa29b-6464-eb6c-e9c9-058963756ec8@ingresso.co.uk> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 17:37:48 -0000 On Mon, 2018-03-12 at 17:21 +0000, Pete French wrote: > > On 10/03/2018 23:48, Ian Lepore wrote: > > > > I based my fix heavily on that patch from the PR, but I rewrote it > > enough that I might've made any number of mistakes, so it needs fresh > > testing.  The main change I made was to make it a lot less noisy while > > waiting (it only mentions the wait once, unless bootverbose is set, in > > which case it's once per second).  I also removed the logic that > > limited the retries to nfs and zfs, because I think we can remove all > > the old code related to waiting that only worked for ufs and let this > > new retry be the way it waits for all filesystems.  But that's a bigger > > change we can do separately; I didn't want to hold up this fix any > > longer. > TThansk for the patch, its is very much appercaited! I applied this  > earlier today, and have been continuously rebooting the machine in Azure  > ever since (every ten minutes). This has worked flawlessly, so I am very  > happy that this fixes the issue for me. I am going to leave it running  > though, just to see if anything happens. I havent examined dmesg, but I  > thould be able to see the output from the patch there to verify that its  > waiting, yes ? > > cheers, > > -pete. Yes, if the root filesystem isn't available on the first attempt, it should emit a single line saying it will wait for up to N seconds for it to arrive, where N is the vfs.mountroot.timeout value (3 seconds if not set in loader.conf). -- Ian From owner-freebsd-stable@freebsd.org Mon Mar 12 22:18:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3F36F4FF9C; Mon, 12 Mar 2018 22:18:17 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 344EE777F9; Mon, 12 Mar 2018 22:18:17 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: by mail-ua0-x242.google.com with SMTP id c14so7916302uak.7; Mon, 12 Mar 2018 15:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Yc3dGhWuBJH+uN3w68cIQ7LnX5govoeC1Inhaa3H3IM=; b=dkdul6Vci7YodimGZEqmP4A5mUe4ZAmvNMMsqg/pikburjSm6R0FRjm9aSbNhgKAUU D3wdm+VK4xMFjtFMtt22phj6dh409zuAiKn1HWIKIraKCGWJO8Cr4hTLZqriAeCJS+Q2 XC3coqBjfJnlG2Ez7EJKdc/O3D+2CeQaZOMMRhC4VmMiuIfgHDcoy0rPdLuvkrjwxk5j SPsbWBXSU16xiAKfjjpgkLooylw1pd1JiOWNmEqjB4txmC6S3feH4BnkpGuA9xIjKcM1 OnQo6KBb6+riY+DrtGTpFFC3kW55y9qTWlfr3xUrXIH+COsltsFc+lkO0UvQFyURybkM p0dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yc3dGhWuBJH+uN3w68cIQ7LnX5govoeC1Inhaa3H3IM=; b=MHcHnq88XvLZzweAAP+EJp2PkAHohhRc//z12rPL5QECe032RuEcEZK5RGABdeCZ1z pV/2oB4VlzbnSE7Vh6OXbYCh/F3mfkOKnTENRNtuRA7SRdhT9QpzG7Web0aG6Y46BRxF aMwMxPZr2e9auhgaTqH1bnOZ2jDCWVfhqAS2MLIMiEH7x3MJCl8WpZ2ICOc6SIM6xk0o B4UAf5ab3aNvutU/vXul3KmQdg95Opp5w21HuVyJEAi11MHbrDuFgZl075qCmfZZRzTr MHyYKqy440uqTfnB9cZaaBqjMHxXgDbEZyQKheCCuWBAZVmR+tiXuTZUeHdtghc/m8UM GSSg== X-Gm-Message-State: AElRT7EOFYtyJcSNT7t34L/4gr3V473FHZwr565P7h5AXGhWfwzhCQ/i 3Psx4RSXFopwC1f7iadRxCUNawyB+T6ME4TlZf1IDw== X-Google-Smtp-Source: AG47ELs2tzW3Mlq4ihe6a8vk1EHpmsJk0+htOSCVhEgNsKBZcKB70lxdQDmFOWI7FmIgd7jSi3DZWX8mx6gLCH6C1Lg= X-Received: by 10.176.75.216 with SMTP id b24mr6290580uag.137.1520893095160; Mon, 12 Mar 2018 15:18:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.73.195 with HTTP; Mon, 12 Mar 2018 15:18:14 -0700 (PDT) From: Rick Miller Date: Mon, 12 Mar 2018 18:18:14 -0400 Message-ID: Subject: FreeBSD 11.x fails to boot w/ SAS3 4Kn HDD and LSISAS3008 on SuperMicro X10DRH-iT To: FreeBSD Questions , freebsd-geom@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 22:18:18 -0000 Hi all, Thanks in advance to anyone that might be able to help. I subscribed to freebsd-geom@ so that the list did not need to "reply-all". Having trouble getting FreeBSD 11-STABLE @ r329011 to boot from SAS3 4Kn HDDs via LSISAS 3008 HBA on a SuperMicro X10DRH-iT motherboard after an apparent installation. All internal media (including all other disks attached to the HBA) were removed to eliminate other storage being the reason the system won't boot. This occurs specifically in CSM mode, but the preference is to boot via UEFI mode instead. Anyway...booting the machine via the memstick image demonstrates the LSISAS 3008 controller attaching via mpr(4) (whose manpage describes the controller being supported[1]): mpr0@pci0:3:0:0: class=0x010700 card=0x080815d9 chip=0x00971000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS3008 PCI-Express Fusion-MPT SAS-3' class = mass storage subclass = SAS The only inserted disk attaches as da0 as illustrated by dmesg: ses0: pass0,da0: Elemne t descriptor: 'Slot00' da0 at mpr0 bus 0 scbus0 target 8 lun 0 ses0: pass0,da0: SAS Device Slot Element: 1 Phys at Slot 0 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: initiator( None ) Target( SSP ) ses0: phy 0: parent 500304801e870bff addr 5000c500a012814d da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number $serial_number da0: 1200.000MB/s transfers da0: Command queueing enabled da0: 1907729MB (488378648 4096 byte sectors) The original goal was to boot via zfs root, but when that failed, subsequent installations used the "Auto (UFS) option" to partition the disk. For example, the first installation gpart'd the disk as: # gpart show da0 => 6 488378635 da0 GPT (1.8T) 6 128 1 freebsd-boot (512K) 134 487325568 2 freebsd-ufs (1.8T) 487325702 1048576 3 freebsd-swap (4.0G) 488374278 4363 - free - (17M) The result was a reboot loop. When the system reached the point of reading the disk, it just rebooted and continued doing so. There was no loader or beastie menu. Thus, thinking that it could be the partition layout requirements of the 4Kn disks, it was gpart'd like the below[2][3]. This was done by exiting to the shell during the partition phase of bsdinstall and manually gpart'ing the disk according to the below, mounting da0p2 at /mnt and placing an fstab at /tmp/bsdinstall_etc/fstab that included mount entries for /dev/da0p2 at / and /dev/da0p3 as swap. # gpart show da0 => 6 488378635 da0 GPT (1.8T) 6 34 - free - (136K) 40 512 1 freebsd-boot (2.0M) 552 419430400 2 freebsd-ufs (1.6T) 419430952 1048576 3 freebsd-swap (4.0G) 420479528 67899113 - free - (259G) When configured as such, the system rebooted at the completion of the install and appeared to roll through the boot order, which specifies the HDD first, then CD/DVD, then network. It did attempt to boot via network, but is irrelevant here. All the hardware is alleged to be supported by FreeBSD as best I can tell and OS installation apparently works. I'm at a loss as to why the OS won't boot. Does someone have feedback or input that may expose why it doesn't boot? FWIW, a RHEL7 install was also attempted, which also does not boot. [1] https://www.freebsd.org/cgi/man.cgi?query=mpr&apropos=0&sektion=4&manpath=FreeBSD+11.1-RELEASE&arch=default&format=html [2] https://lists.freebsd.org/pipermail/freebsd-hardware/ 2013-September/007380.html [3] http://www.wonkity.com/~wblock/docs/html/disksetup.html -- Take care Rick Miller From owner-freebsd-stable@freebsd.org Tue Mar 13 02:00:15 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D556AF9BD1 for ; Tue, 13 Mar 2018 02:00:15 +0000 (UTC) (envelope-from joseph@mulloy.me) Received: from mail.vps-vu-nj-1b.jdmulloy.com (mail.vps-vu-nj-1b.jdmulloy.com [IPv6:2001:19f0:5:6a3::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F6A080435 for ; Tue, 13 Mar 2018 02:00:15 +0000 (UTC) (envelope-from joseph@mulloy.me) Received: from mail.jdmulloy.net (pool-108-7-195-9.bstnma.fios.verizon.net [108.7.195.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail.jdmulloy.net", Issuer "Mulloy SMTP Client Certificate Authority" (verified OK)) by mail.vps-vu-nj-1b.jdmulloy.com (Postfix) with ESMTPS id 31DB719B7F8 for ; Tue, 13 Mar 2018 02:00:14 +0000 (UTC) Received: from aluminium.jdmulloy.net (aluminium.jdmulloy.net [10.2.1.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.jdmulloy.net (Postfix) with ESMTPSA id A4FCC17F72 for ; Tue, 13 Mar 2018 02:00:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mulloy.me; s=2015-07; t=1520906413; i=@mulloy.me; bh=VESkpHXCOuMXNQTm17p3Pudj9dobHhYVDNrFgYfsTXY=; h=To:From:Subject:Date; b=dRVUpzq1jF3TjsScKXmX+aOIK2Efgz++k9Q8CjQqJEyxNMcPKabKGazGwJ0eYF77F pzXz+8YP93i/f1P85uwAKOLZ4mE//VynCfKdpcxmptOVfN6l2r6OE566Ut6baGcrW/ Jl7ffWyhzXSnDxsoLfImghevEuFqrz8Hasuo/ylbGJ1k/uQnNO4AaND3wE4lHX/ZbY BYbEPhpnqHtssohpqTZ+c43JUIeim8LxNQdmQpouRS2BYsUZqliuJi47DkflmO682x dizQ4au6UNXONYGJKi/gAn/DiuvPs5XDn61aE/VN4zFxv/1eBw82bM+O1Xgpcstcev rF0+8hLyQOnDg== To: freebsd-stable@freebsd.org From: Joseph Mulloy Subject: Re: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge Message-ID: Date: Mon, 12 Mar 2018 22:00:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 02:00:15 -0000 Hi, I'm trying to test the Meltdown mitigation by applying the patch at https://people.freebsd.org/~emaste/patches/amd64_11.1_meltdown.3.patch and I'm getting a ton of error when I try to build the kernel with "make buildkernel". I've tried applying the patch against release/11.1.0 and releng/11.1 and they both fail with the same compiler errors. I tried running make clean and that doesn't fix it. I'm probably doing something wrong, I couldn't find any instructions on how to apply the patch, it took me a while to figure it out even with the man page. Perhaps there's some step in the process that I don't know about. I haven't been able to find any docs about doing this sort of thing. Thanks for any help you can provide. I would like to help with the testing. I'm applying the patch with the following command and it seems to apply just fine. patch < amd64_11.1_meltdown.3.patch This is the output of svn info root@server1:/usr/src # svnlite info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/release/11.1.0 Relative URL: ^/release/11.1.0 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 330824 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 321354 Last Changed Date: 2017-07-21 20:55:38 +0000 (Fri, 21 Jul 2017) Below are the compiler errors I'm getting. -------------------------------------------------------------- >>> stage 3.1: building everything -------------------------------------------------------------- cd /usr/obj/usr/src/sys/GENERIC; COMPILER_VERSION=40000 COMPILER_FEATURES=c++11 COMPILER_TYPE=clang COMPILER_FREEBSD_VERSION=1100504 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/us r/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc -target x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -targ et x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" NM=nm OBJDUMP=objdump OBJ COPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tm p/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ machine -> /usr/src/sys/amd64/include x86 -> /usr/src/sys/x86/include cc -target x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_glob al.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wre dundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tau tological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 /usr/src/sys/amd64/amd64/ genassym.c /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:38:21: note: expanded from macro 'ASSYM' char name ## sign[((value) < 0 ? 1 : 0) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:39:28: note: expanded from macro 'ASSYM' char name ## w0[(ASSYM_ABS(value) & 0xFFFFU) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:28: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:39:28: note: expanded from macro 'ASSYM' char name ## w0[(ASSYM_ABS(value) & 0xFFFFU) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:44: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:39:28: note: expanded from macro 'ASSYM' char name ## w0[(ASSYM_ABS(value) & 0xFFFFU) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:66: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:40:29: note: expanded from macro 'ASSYM' char name ## w1[((ASSYM_ABS(value) & 0xFFFF0000UL) >> 16) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:28: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:40:29: note: expanded from macro 'ASSYM' char name ## w1[((ASSYM_ABS(value) & 0xFFFF0000UL) >> 16) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:44: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:40:29: note: expanded from macro 'ASSYM' char name ## w1[((ASSYM_ABS(value) & 0xFFFF0000UL) >> 16) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:66: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:41:29: note: expanded from macro 'ASSYM' char name ## w2[((ASSYM_ABS(value) & 0xFFFF00000000ULL) >> 32) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:28: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:41:29: note: expanded from macro 'ASSYM' char name ## w2[((ASSYM_ABS(value) & 0xFFFF00000000ULL) >> 32) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:44: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:41:29: note: expanded from macro 'ASSYM' char name ## w2[((ASSYM_ABS(value) & 0xFFFF00000000ULL) >> 32) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:66: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:42:29: note: expanded from macro 'ASSYM' char name ## w3[((ASSYM_ABS(value) & 0xFFFF000000000000ULL) >> 48) + ASSYM_BIAS] ^~~~~ /usr/src/sys/sys/assym.h:35:28: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:42:29: note: expanded from macro 'ASSYM' char name ## w3[((ASSYM_ABS(value) & 0xFFFF000000000000ULL) >> 48) + ASSYM_BIAS] ^~~~~ /usr/src/sys/sys/assym.h:35:44: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:42:29: note: expanded from macro 'ASSYM' char name ## w3[((ASSYM_ABS(value) & 0xFFFF000000000000ULL) >> 48) + ASSYM_BIAS] ^~~~~ /usr/src/sys/sys/assym.h:35:66: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:195:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RAX, offsetof(struct pti_frame, pti_rax)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:38:21: note: expanded from macro 'ASSYM' char name ## sign[((value) < 0 ? 1 : 0) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:195:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RAX, offsetof(struct pti_frame, pti_rax)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:39:28: note: expanded from macro 'ASSYM' char name ## w0[(ASSYM_ABS(value) & 0xFFFFU) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:28: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:195:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RAX, offsetof(struct pti_frame, pti_rax)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:39:28: note: expanded from macro 'ASSYM' char name ## w0[(ASSYM_ABS(value) & 0xFFFFU) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:44: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:195:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RAX, offsetof(struct pti_frame, pti_rax)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:39:28: note: expanded from macro 'ASSYM' char name ## w0[(ASSYM_ABS(value) & 0xFFFFU) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:66: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:195:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RAX, offsetof(struct pti_frame, pti_rax)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:40:29: note: expanded from macro 'ASSYM' char name ## w1[((ASSYM_ABS(value) & 0xFFFF0000UL) >> 16) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:28: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ /usr/src/sys/amd64/amd64/genassym.c:195:16: error: offsetof of incomplete type 'struct pti_frame' ASSYM(PTI_RAX, offsetof(struct pti_frame, pti_rax)); ^ ~~~~~~ /usr/src/sys/sys/types.h:292:31: note: expanded from macro 'offsetof' #define offsetof(type, field) __offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/cdefs.h:492:34: note: expanded from macro '__offsetof' #define __offsetof(type, field) __builtin_offsetof(type, field) ^ ~~~~ /usr/src/sys/sys/assym.h:40:29: note: expanded from macro 'ASSYM' char name ## w1[((ASSYM_ABS(value) & 0xFFFF0000UL) >> 16) + ASSYM_BIAS]; \ ^~~~~ /usr/src/sys/sys/assym.h:35:44: note: expanded from macro 'ASSYM_ABS' #define ASSYM_ABS(value) ((value) < 0 ? -((value) + 1) + 1ULL : (value)) ^~~~~ /usr/src/sys/amd64/amd64/genassym.c:194:32: note: forward declaration of 'struct pti_frame' ASSYM(PTI_RDX, offsetof(struct pti_frame, pti_rdx)); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src From owner-freebsd-stable@freebsd.org Tue Mar 13 02:10:56 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A780FAFB0ED for ; Tue, 13 Mar 2018 02:10:56 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12AAE80EE9 for ; Tue, 13 Mar 2018 02:10:56 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id r8so2985055wrg.0 for ; Mon, 12 Mar 2018 19:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=VWicC0V2ctMNC9UC4quRbwbzcsik01oRagHbRhKvXgE=; b=Mq6mK1D7mfkotSGEPQTf+MM83YFYS1wLgX9lhkImIaQ85u4GcrBerxJeMLQ/ZFJKGw NiR9LvLvXgdECTjlckmoqvuulF3l6oMuvnQmcnQOw4v8+fzdURYJieCiIXV+ZYc6Usq7 uLvQHefPkr38p1sKWXHGrD/j4O28biEm8V1xz4jXb0+n2i83epiQ+wpnkLKU4YZbQQ8t eL5mizHc8ffuCdsHmzAKSvOATXOPDJfjUpAz9OhZDmF7pwNr0KmY1B6dQw8T/5lL18jQ nMGZGTtSvWQmGRfC4EIvxXqxI42TaobZaOZc9XaEx7qUr/Ukjx4RnxSwaR45Q3zPGGO+ UQ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=VWicC0V2ctMNC9UC4quRbwbzcsik01oRagHbRhKvXgE=; b=UhcwaRdCNv9eFAQ9F6Cx0x9ZN7BzgU3xYGtRVdt2Xjn1nD4sPbrZUSL3pPyCl1Q72r 3Q7DUw71gHtcpX+HTeDOmqZUnv6SvJz9IzplJ1S88ol34bMaTtSGZTuYViNkA0F7ijfj zLhlMb9tWeLClfdMS1xjQmMavfkK2Ls3188KbBdxFqNR+aVa1gCT+Fki+TWS1XSzCnU/ 83/lq79DgKdJMGSVKJQ8KgInzysdDXQ/ArnOQMHSZpa6XGnrKqKNpp6UHLKw+F8GOJOB IE/IUrlOCFEZ01DOCzSc6EYs/rimTv1fcA3p6ntyjJAUJM3y4jV7tqnMjHWc1M7UQCW3 +OXA== X-Gm-Message-State: AElRT7F7/x41F6OfDeiS8soQlh3Tlmtdphh7PSPrLvnJJ4VDjoTKzd5X onuxaXe/aJ7a+qGxn2IkJEUA6i26HiNXUeUHjZ5pEA== X-Google-Smtp-Source: AG47ELs6LS6223wgFO/gxTuzs4DLEVj7cJKrwMin7WPfcaKpUqH2wL+dcd8NNrydWoAfouZ/L29JQB/LRM98d1a5pM8= X-Received: by 10.80.153.157 with SMTP id m29mr13213782edb.145.1520907054891; Mon, 12 Mar 2018 19:10:54 -0700 (PDT) MIME-Version: 1.0 Sender: jdavidlists@gmail.com Received: by 10.80.221.75 with HTTP; Mon, 12 Mar 2018 19:10:54 -0700 (PDT) In-Reply-To: References: From: J David Date: Mon, 12 Mar 2018 22:10:54 -0400 X-Google-Sender-Auth: LxfT-scg_kYDBFhY5QaOXSNdGdE Message-ID: Subject: Re: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge To: Joseph Mulloy Cc: freebsd-stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 02:10:56 -0000 On Mon, Mar 12, 2018 at 10:00 PM, Joseph Mulloy wrote: > /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete > type =E2=80=98struct pti_frame' This might be the error you get if frame.h did not patch correctly. It=E2=80=99s a known issue with the patch (the SVN tag doesn=E2=80=99t matc= h). Check for a /usr/src/sys/amd64/include/frame.h.rej file. If so, just fix the SVN tag and re-apply and it should build correctly. If that=E2=80=99s your issue, there should be an updated version available soon, if not already. Good luck! From owner-freebsd-stable@freebsd.org Tue Mar 13 03:32:55 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 749F9B7BBB3 for ; Tue, 13 Mar 2018 03:32:55 +0000 (UTC) (envelope-from joseph@mulloy.me) Received: from mail.vps-vu-nj-1a.jdmulloy.com (mail.vps-vu-nj-1a.jdmulloy.com [IPv6:2001:19f0:5:331::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E2C2859C0 for ; Tue, 13 Mar 2018 03:32:55 +0000 (UTC) (envelope-from joseph@mulloy.me) Received: from mail.jdmulloy.net (pool-108-7-195-9.bstnma.fios.verizon.net [108.7.195.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail.jdmulloy.net", Issuer "Mulloy SMTP Client Certificate Authority" (verified OK)) by mail.vps-vu-nj-1a.jdmulloy.com (Postfix) with ESMTPS id 7369CFF61A for ; Tue, 13 Mar 2018 03:32:54 +0000 (UTC) Received: from aluminium.jdmulloy.net (aluminium.jdmulloy.net [10.2.1.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.jdmulloy.net (Postfix) with ESMTPSA id EE1D417062 for ; Tue, 13 Mar 2018 03:32:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mulloy.me; s=2015-07; t=1520911974; i=@mulloy.me; bh=2dr/01Wylw+k1TGfw+Ja/ygcf+Rnacwu4QXWLb6uUYE=; h=Subject:To:References:From:Date:In-Reply-To; b=XPSnUZ7dQTfC06qkldav+6OGQLy81F2thLyqcdsU5xVyBA87iytouKzvV5mko2CAY Q9c6ftaLAPSJ3kDjj/Rz0LbXHD72HBVgfg1C+0eCmGZu//ihqkrlmrB+GZ74rTXTA0 V5xX7cDKWltqMS14ZU3VwDJnQTRlXvaSWUybLvHEnVG2OBApy8lJqouWjvU+rVmNQV tr1IhYvuPc2vfdgj+xipwr5u/tGfBYxfX7J7no9FhNfveAzZG78qhw1yGWGhD7jvcp QQ0OvZOFK3VQ4iHYh4o9GkBzbZZBZgnQo49TrNTDT7hU7uHBp9GjPxozZ3zH4jDx1Z xmrCGgp6zjwRg== Subject: Re: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge To: freebsd-stable@freebsd.org References: From: Joseph Mulloy Message-ID: <87c584de-0e22-27eb-ba73-9fc5c34cbe56@mulloy.me> Date: Mon, 12 Mar 2018 23:34:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 03:32:55 -0000 Thanks, It did fail to patch that file. I changed the line with the svn tag to "/* $FreeBSD$ */" to match the patch and it applied successfully. It now compiles successfully. On 3/12/18 10:10 PM, J David wrote: > On Mon, Mar 12, 2018 at 10:00 PM, Joseph Mulloy > wrote: >> /usr/src/sys/amd64/amd64/genassym.c:194:16: error: offsetof of incomplete >> type ‘struct pti_frame' > This might be the error you get if frame.h did not patch correctly. > It’s a known issue with the patch (the SVN tag doesn’t match). > > Check for a /usr/src/sys/amd64/include/frame.h.rej file. > > If so, just fix the SVN tag and re-apply and it should build correctly. > > If that’s your issue, there should be an updated version available > soon, if not already. > > Good luck! > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Tue Mar 13 06:45:19 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 801F5BF4356 for ; Tue, 13 Mar 2018 06:45:19 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6057C6C01C for ; Tue, 13 Mar 2018 06:45:18 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22b.google.com with SMTP id i80-v6so27025652lfg.5 for ; Mon, 12 Mar 2018 23:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uPtwVSGDJlbqM2fO/scs6rfaD/sECYaXk7W+l8olse0=; b=1oMpzSHE3cx96+sZROASjBz8xToeqYyVCrt2hU+0M3DTtnjd5jz0EpXLQE1Kklz3AX EMEd+i8NBDFlsgNhqx1rEE7XxcKItRDbhPFvycDw2V40+GWqRAtzDHvsg5PaFrhacjcY El0uj2hquBiQr8RF9pIem/y3T5VC5+wUE7LzAwGPtaQjHzi+q3EKMOOpgNxysIGKrPVS BKLHjM9BebJhJfrP/zDIkIsp7mxriE+E14Gshnjp41HvzEfG/0CmA6mzGcRO6dEdUU+B G5pO1rdLtDcJ83stGoppO9aG0GdhU0cuSCgP7c4/v1FmkiPomALrNb7FAVVGZyG5X334 +tPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uPtwVSGDJlbqM2fO/scs6rfaD/sECYaXk7W+l8olse0=; b=DfUM1HW1rB37oT1s7g8sxyKInCOV3cssrq8VzFmzYj0Z7Lj5sRz6gg+SOz4vBcoD6p Wo7Xp+lG0c4w0T+V+8HKBI2U2pn+dqiJOPVpv5lSnSp2799Ol+GWnMLKG5oypJU2t6jA zQ28G/A+NZfoATpr0vN854TzTsbA7IofPO8R65zfsnrTjPdFUigtb3eqoS8PnvNaLNae KFEl5XXHuLUn9EgYRVbG5/2O6ltE6N9FeO/1fcx+zXeRRaJFnB82ix37WhmzhFLicqNf Sn3QcUup2cGPFOEq0F6Vg/cXXaSDbLCOeynWpDn04S8ibqNshJrkBSZUcEsdDrMXO6YY 5wKw== X-Gm-Message-State: AElRT7FCct81ZLl+yr/QMnGaXV8x9MpU6UisKq8hbjiRh+UECtn4ZUXK 5VIq5m0APQTUv5G8hHryyhSSPLO7BGoInisRJrWvyA== X-Google-Smtp-Source: AG47ELuul+jwt/q9cA6TJZPKBb+CurDMyiPWx+XXz4dCGIgoufNXuQ/aEXzHMdr8MgVaUHlp+fiVS+oP515MSpWALSI= X-Received: by 2002:a19:c987:: with SMTP id z129-v6mr2540279lff.74.1520923516542; Mon, 12 Mar 2018 23:45:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Hartland Date: Tue, 13 Mar 2018 06:45:05 +0000 Message-ID: Subject: Re: FreeBSD 11.x fails to boot w/ SAS3 4Kn HDD and LSISAS3008 on SuperMicro X10DRH-iT To: Rick Miller Cc: FreeBSD Questions , freebsd-geom@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 06:45:19 -0000 Have you tried setting dumpdev to AUTO in rc.conf to see if you can obtain a panic dump? You could also try disabling reboot on it panic using the sysctl On Mon, 12 Mar 2018 at 22:18, Rick Miller wrote: > Hi all, > > Thanks in advance to anyone that might be able to help. I subscribed to > freebsd-geom@ so that the list did not need to "reply-all". Having trouble > getting FreeBSD 11-STABLE @ r329011 to boot from SAS3 4Kn HDDs via LSISAS > 3008 HBA on a SuperMicro X10DRH-iT motherboard after an apparent > installation. All internal media (including all other disks attached to the > HBA) were removed to eliminate other storage being the reason the system > won't boot. This occurs specifically in CSM mode, but the preference is to > boot via UEFI mode instead. > > Anyway...booting the machine via the memstick image demonstrates the LSISAS > 3008 controller attaching via mpr(4) (whose manpage describes the > controller being supported[1]): > > mpr0@pci0:3:0:0: class=0x010700 card=0x080815d9 chip=0x00971000 rev=0x02 > hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = 'SAS3008 PCI-Express Fusion-MPT SAS-3' > class = mass storage > subclass = SAS > > The only inserted disk attaches as da0 as illustrated by dmesg: > > ses0: pass0,da0: Elemne t descriptor: 'Slot00' > da0 at mpr0 bus 0 scbus0 target 8 lun 0 > ses0: pass0,da0: SAS Device Slot Element: 1 Phys at Slot 0 > ses0: phy 0: SAS device type 1 id 0 > ses0: phy 0: protocols: initiator( None ) Target( SSP ) > ses0: phy 0: parent 500304801e870bff addr 5000c500a012814d > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number $serial_number > da0: 1200.000MB/s transfers > da0: Command queueing enabled > da0: 1907729MB (488378648 4096 byte sectors) > > The original goal was to boot via zfs root, but when that failed, > subsequent installations used the "Auto (UFS) option" to partition the > disk. For example, the first installation gpart'd the disk as: > > # gpart show da0 > => 6 488378635 da0 GPT (1.8T) > 6 128 1 freebsd-boot (512K) > 134 487325568 2 freebsd-ufs (1.8T) > 487325702 1048576 3 freebsd-swap (4.0G) > 488374278 4363 - free - (17M) > > The result was a reboot loop. When the system reached the point of reading > the disk, it just rebooted and continued doing so. There was no loader or > beastie menu. Thus, thinking that it could be the partition layout > requirements of the 4Kn disks, it was gpart'd like the below[2][3]. This > was done by exiting to the shell during the partition phase of bsdinstall > and manually gpart'ing the disk according to the below, mounting da0p2 at > /mnt and placing an fstab at /tmp/bsdinstall_etc/fstab that included mount > entries for /dev/da0p2 at / and /dev/da0p3 as swap. > > # gpart show da0 > => 6 488378635 da0 GPT (1.8T) > 6 34 - free - (136K) > 40 512 1 freebsd-boot (2.0M) > 552 419430400 2 freebsd-ufs (1.6T) > 419430952 1048576 3 freebsd-swap (4.0G) > 420479528 67899113 - free - (259G) > > When configured as such, the system rebooted at the completion of the > install and appeared to roll through the boot order, which specifies the > HDD first, then CD/DVD, then network. It did attempt to boot via network, > but is irrelevant here. > > All the hardware is alleged to be supported by FreeBSD as best I can tell > and OS installation apparently works. I'm at a loss as to why the OS won't > boot. Does someone have feedback or input that may expose why it doesn't > boot? > > FWIW, a RHEL7 install was also attempted, which also does not boot. > > [1] > > https://www.freebsd.org/cgi/man.cgi?query=mpr&apropos=0&sektion=4&manpath=FreeBSD+11.1-RELEASE&arch=default&format=html > [2] https://lists.freebsd.org/pipermail/freebsd-hardware/ > 2013-September/007380.html > [3] http://www.wonkity.com/~wblock/docs/html/disksetup.html > > -- > Take care > Rick Miller > _______________________________________________ > freebsd-geom@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Tue Mar 13 07:40:23 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8803A807 for ; Tue, 13 Mar 2018 07:40:23 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id D1BB26DEE0; Tue, 13 Mar 2018 07:40:22 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Tue, 13 Mar 2018 08:37:36 +0100 Authentication-Results: connect.ultra-secure.de; auth=pass (login); spf=none smtp.mailfrom=ultra-secure.de Received-SPF: None (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.10 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.10; helo=connect.ultra-secure.de; envelope-from= Received: from connect.ultra-secure.de (webmail [127.0.0.10]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id 1C8555E9-2E4F-465E-AFCA-8F0227B20D29.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Tue, 13 Mar 2018 08:37:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 13 Mar 2018 08:37:30 +0100 From: rainer@ultra-secure.de To: Ed Maste Cc: freebsd-stable@freebsd.org Subject: Re: Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge In-Reply-To: <20180306164125.GA61857@freebsd.org> References: <20180306164125.GA61857@freebsd.org> Message-ID: <21fc56d15e8fbbf654abfadd46ac720e@ultra-secure.de> X-Sender: rainer@ultra-secure.de User-Agent: Roundcube Webmail/1.2.0 X-Haraka-GeoIP: --, , NaNkm X-Haraka-GeoIP-Received: X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 511, bad: 0, connections: 517, history: 511, pass:all_good, relaying X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 07:40:23 -0000 Am 2018-03-06 17:41, schrieb Ed Maste: > Background > ---------- > > A number of issues relating to speculative execution were found last > year and publicly announced January 3rd. A variety of techniques used > to > mitigate these issues have been committed to FreeBSD-CURRENT and have > been merged to the stable/11 branch. > > The changes will be merged and released as an update to FreeBSD > 11.1-RELEASE in the near future, but the candidate patch is now > available for broader testing. Hi, would it be possible to provide a) patched binaries b) an installer for these binaries c) a simple tool to backup the original binaries and restore them ? Ever since binary patches became available, I've not bothered building FreeBSD any more. None of my systems have the source, nor do I want to install it anywhere. I'm also not bothering to install this in a VM - you guys have probably done this a few times. Regards Rainer From owner-freebsd-stable@freebsd.org Tue Mar 13 09:47:59 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A4B7F33C80 for ; Tue, 13 Mar 2018 09:47:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B226673B39; Tue, 13 Mar 2018 09:47:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2D9b4cW003549 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Mar 2018 10:37:05 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-stable@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id w2D9b0C0034713; Tue, 13 Mar 2018 16:37:00 +0700 (+07) (envelope-from eugen@grosbein.net) To: FreeBSD Stable From: Eugene Grosbein Subject: GEOM strange error X-Enigmail-Draft-Status: N1110 Cc: Alexander Motin Message-ID: <5AA79BBC.70009@grosbein.net> Date: Tue, 13 Mar 2018 16:37:00 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 1.0 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: *** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 09:47:59 -0000 Hi! Let's create a stripe and GPT over it using test files as backing store: truncate -s 1G d0 truncate -s 1G d1 mdconfig -af d0 # gives md0 mdconfig -af d1 # gives md1 gpart create -s GPT md0 gpart create -s GPT md1 gpart destroy -F md1 gpart destroy -F md0 # no errors still gstripe label -s $((128*1024)) st0 md0 md1 gpart create -s GPT /dev/stripe/st0 dmesg -a GEOM_STRIPE: Device st0 created (id=4000112224). GEOM_STRIPE: Disk md0 attached to st0. GEOM_STRIPE: Disk md1 attached to st0. GEOM_STRIPE: Device stripe/st0 activated. GEOM: md0: corrupt or invalid GPT detected. GEOM: md0: GPT rejected -- may not be recoverable. Why does it emit such md0-related error? From owner-freebsd-stable@freebsd.org Tue Mar 13 10:44:43 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7C8BF3A01C for ; Tue, 13 Mar 2018 10:44:43 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 291F9762A3; Tue, 13 Mar 2018 10:44:43 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f50.google.com with SMTP id i80-v6so28004554lfg.5; Tue, 13 Mar 2018 03:44:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=abRs1xSvQCsblMQy4oai3hA41pavCOAwZJqLczRfr4w=; b=ZItZAr12D0LQgsuwvEAmIVaRlM+4I8GFxzQDw7MiiYUHnlAY00tmHWEKd92b67C/kr hm0mrQBl+OvS4P2a/fnqEcZHAjE5fDFEN/KS+o4cigPAIzdd2tktt9w9VqJDt7yBoCH/ 0KnCYIqvDs4S7TefXaEL2Rr8pSQi+Swd51Qz/5IyuTRp+lkZp2lkkCnC4sZ2elxJzyXk xz4azwESw7tghLn4ZtHtj/C/jTlYeuqm8GVxlqRTsDoHCpNpU1Y8XOmckf6FQgMy23PP UucrYuTeOxP4AeNvHfXyPXvblLNYeGo+iP0zrJs1veENG+orIMrjY3oSixE4aRNf0hJm unkw== X-Gm-Message-State: AElRT7EwFRG8lnmYp0QkL73AtuuLGKNyDvVmcKMi3YxpbfILL7KYVyxn A3RtaIHgiKDi+Tx4PSxtXy5fIbHs X-Google-Smtp-Source: AG47ELvzJ0oYrAVRBcr8OIcBmMYuYt4odQQSjQWogU6nxpB7Uxrxr46lha0hVIKZa7opnRkoYuv2Sg== X-Received: by 2002:a19:18d7:: with SMTP id 84-v6mr71487lfy.117.1520937560149; Tue, 13 Mar 2018 03:39:20 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id k8sm12891ljk.63.2018.03.13.03.39.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 03:39:19 -0700 (PDT) Subject: Re: GEOM strange error To: Eugene Grosbein , FreeBSD Stable Cc: Alexander Motin References: <5AA79BBC.70009@grosbein.net> From: Andriy Gapon Message-ID: Date: Tue, 13 Mar 2018 12:39:18 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AA79BBC.70009@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 10:44:43 -0000 On 13/03/2018 11:37, Eugene Grosbein wrote: > Hi! > > Let's create a stripe and GPT over it using test files as backing store: > > truncate -s 1G d0 > truncate -s 1G d1 > mdconfig -af d0 # gives md0 > mdconfig -af d1 # gives md1 > > gpart create -s GPT md0 > gpart create -s GPT md1 > gpart destroy -F md1 > gpart destroy -F md0 # no errors still > > gstripe label -s $((128*1024)) st0 md0 md1 > gpart create -s GPT /dev/stripe/st0 > dmesg -a > > GEOM_STRIPE: Device st0 created (id=4000112224). > GEOM_STRIPE: Disk md0 attached to st0. > GEOM_STRIPE: Disk md1 attached to st0. > GEOM_STRIPE: Device stripe/st0 activated. > GEOM: md0: corrupt or invalid GPT detected. > GEOM: md0: GPT rejected -- may not be recoverable. > > Why does it emit such md0-related error? When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are open for writing too. Afterwards, the write access count is cleared from three of them and that triggers re-tasting. I guess that g_part code tries to taste md0 and md1 and sees the GPT label at the start of md0 and the label is correctly rejected because it's inconsistent with md0's parameters. -- Andriy Gapon From owner-freebsd-stable@freebsd.org Tue Mar 13 10:51:44 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A71A4F3AB12 for ; Tue, 13 Mar 2018 10:51:44 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2a02:b90:3002:411::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4407C76936; Tue, 13 Mar 2018 10:51:44 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6]) by constantine.ingresso.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1evhWv-000Ili-DH; Tue, 13 Mar 2018 10:51:41 +0000 Subject: Re: zfs problems after rebuilding system [SOLVED] To: Ian Lepore , freebsd-stable@freebsd.org References: <21c64a2d-b9f9-24c8-88ec-ff1210891f60@zyxst.net> <65372449-53f1-8002-981a-e20f4a592e26@zyxst.net> <5CFC89E9-57BE-4CB7-9C55-0D3CCF1E8D3D@FreeBSD.org> <20180303234236.M3811@besplex.bde.org> <9b3cd942-347c-44a2-60d6-0b3c4a45552f@ingresso.co.uk> <1520723109.84937.136.camel@freebsd.org> <84146241-12d3-8333-0687-c2377838f175@ingresso.co.uk> <1520723722.84937.139.camel@freebsd.org> <217437b9-9879-8919-966a-45cf5eb58d33@ingresso.co.uk> <1520725685.84937.144.camel@freebsd.org> From: Pete French Message-ID: Date: Tue, 13 Mar 2018 10:51:41 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1520725685.84937.144.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 10:51:44 -0000 > I based my fix heavily on that patch from the PR, but I rewrote it > enough that I might've made any number of mistakes, so it needs fresh > testing. Ok, have been rebooting with the patch eery ten minutes for 24 hours now, and it comes back up perfectly every time, so as far as I am concerned thats sufficient testing for me to say its fixed and I would be very happy to have it merged into STABLE (and I;ll then roll it out everywhere). Thanks! -pete. From owner-freebsd-stable@freebsd.org Tue Mar 13 11:52:32 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97F40F41F46 for ; Tue, 13 Mar 2018 11:52:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BBCE278C3C; Tue, 13 Mar 2018 11:52:31 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w2DBqNk6004605 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Mar 2018 12:52:23 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: avg@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id w2DBqJG6039585; Tue, 13 Mar 2018 18:52:19 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: GEOM strange error To: Andriy Gapon , FreeBSD Stable References: <5AA79BBC.70009@grosbein.net> Cc: Alexander Motin From: Eugene Grosbein Message-ID: <5AA7BB73.7090008@grosbein.net> Date: Tue, 13 Mar 2018 18:52:19 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 1.0 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: *** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 11:52:32 -0000 On 13.03.2018 17:39, Andriy Gapon wrote: > On 13/03/2018 11:37, Eugene Grosbein wrote: >> Hi! >> >> Let's create a stripe and GPT over it using test files as backing store: >> >> truncate -s 1G d0 >> truncate -s 1G d1 >> mdconfig -af d0 # gives md0 >> mdconfig -af d1 # gives md1 >> >> gpart create -s GPT md0 >> gpart create -s GPT md1 >> gpart destroy -F md1 >> gpart destroy -F md0 # no errors still >> >> gstripe label -s $((128*1024)) st0 md0 md1 >> gpart create -s GPT /dev/stripe/st0 >> dmesg -a >> >> GEOM_STRIPE: Device st0 created (id=4000112224). >> GEOM_STRIPE: Disk md0 attached to st0. >> GEOM_STRIPE: Disk md1 attached to st0. >> GEOM_STRIPE: Device stripe/st0 activated. >> GEOM: md0: corrupt or invalid GPT detected. >> GEOM: md0: GPT rejected -- may not be recoverable. >> >> Why does it emit such md0-related error? > > When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are > open for writing too. Afterwards, the write access count is cleared from three > of them and that triggers re-tasting. I guess that g_part code tries to taste > md0 and md1 and sees the GPT label at the start of md0 and the label is > correctly rejected because it's inconsistent with md0's parameters. Shouldn't gstripe grab its components for exclusive access? So that GEOM does not even try to treat md[01] as targets for re-tasting. From owner-freebsd-stable@freebsd.org Tue Mar 13 12:14:15 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AE33F464D0 for ; Tue, 13 Mar 2018 12:14:15 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BCEA79D9F; Tue, 13 Mar 2018 12:14:14 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f48.google.com with SMTP id m69-v6so28380328lfe.8; Tue, 13 Mar 2018 05:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8PHnlDJvuxS5bXpPQr8jPG/TaXTbwXQCdGiJ4ugsD8Y=; b=TSLF03r8/YCc2sVrTdR1vb9kKmUjIfH393jaWBGuy35410aQAPuxcxJmYqnEH2e93h LyQOqn4xpSGkLchWepOS9TQ9f3/vM5+24tfWFDe9c04r1KEF0wrUb/ar1EFNdFQkuORd 2LMytdr++NqjP3dcu0G3Y6AV32K96PLOXhHYQN1J4nErKroXYGzLU+o1pCOfSgAs2M3/ Eief0k/9SCI5D5uOfCdztyabyJqa4MZdxpN7Dp2MbIggeFO3HVXIdZBVByxvcNFJ9LeX LFAHJzA6UsO2/lzONH3wp0Rv71RvYNGeBCGrJTN+YrDIQ2TDiYZxXPpR780C3UlG1Wib N6lw== X-Gm-Message-State: AElRT7EYxoI9lm0tp9zqK6OGINZXGK9kdBCk/PzFMBR8eQurX5iRNFqh lQxvE47J1xYzw080Jy7CkjYai0gJ X-Google-Smtp-Source: AG47ELudD16Vz6DZ9g8nrbDsEnqSDfysucOA5dnvd/uQXUe0NJUDkKNFhPPZOJrxkVBcgrtzSKP+IQ== X-Received: by 10.46.89.28 with SMTP id n28mr292312ljb.73.1520943246688; Tue, 13 Mar 2018 05:14:06 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id h23-v6sm12308lfj.87.2018.03.13.05.14.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 05:14:05 -0700 (PDT) Subject: Re: GEOM strange error To: Eugene Grosbein , FreeBSD Stable Cc: Alexander Motin References: <5AA79BBC.70009@grosbein.net> <5AA7BB73.7090008@grosbein.net> From: Andriy Gapon Message-ID: <13234bc1-5c04-1d6b-83e8-21282b038eaa@FreeBSD.org> Date: Tue, 13 Mar 2018 14:14:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AA7BB73.7090008@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 12:14:15 -0000 On 13/03/2018 13:52, Eugene Grosbein wrote: > On 13.03.2018 17:39, Andriy Gapon wrote: >> On 13/03/2018 11:37, Eugene Grosbein wrote: >>> Hi! >>> >>> Let's create a stripe and GPT over it using test files as backing store: >>> >>> truncate -s 1G d0 >>> truncate -s 1G d1 >>> mdconfig -af d0 # gives md0 >>> mdconfig -af d1 # gives md1 >>> >>> gpart create -s GPT md0 >>> gpart create -s GPT md1 >>> gpart destroy -F md1 >>> gpart destroy -F md0 # no errors still >>> >>> gstripe label -s $((128*1024)) st0 md0 md1 >>> gpart create -s GPT /dev/stripe/st0 >>> dmesg -a >>> >>> GEOM_STRIPE: Device st0 created (id=4000112224). >>> GEOM_STRIPE: Disk md0 attached to st0. >>> GEOM_STRIPE: Disk md1 attached to st0. >>> GEOM_STRIPE: Device stripe/st0 activated. >>> GEOM: md0: corrupt or invalid GPT detected. >>> GEOM: md0: GPT rejected -- may not be recoverable. >>> >>> Why does it emit such md0-related error? >> >> When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are >> open for writing too. Afterwards, the write access count is cleared from three >> of them and that triggers re-tasting. I guess that g_part code tries to taste >> md0 and md1 and sees the GPT label at the start of md0 and the label is >> correctly rejected because it's inconsistent with md0's parameters. > > Shouldn't gstripe grab its components for exclusive access? > So that GEOM does not even try to treat md[01] as targets for re-tasting. I don't know what it should do, but I see that it doesn't do it in the "idle" state. However, when the stripe itself is opened / accessed, then it does add the exclusive bit to requested access counts. See g_stripe_access(). I think that what you expected makes more sense for me than what the code actually does. -- Andriy Gapon From owner-freebsd-stable@freebsd.org Tue Mar 13 12:25:59 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6862F4955A; Tue, 13 Mar 2018 12:25:58 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52F2A7A499; Tue, 13 Mar 2018 12:25:58 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: by mail-ua0-x231.google.com with SMTP id c40so9044186uae.2; Tue, 13 Mar 2018 05:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SeGlG3ooT8T8szI81EK2LLLSBaO8vVI8uYji8Z3GIks=; b=K/Q9Q7PfeToYHrjjIVjbkw6jtkWoZuDcOOazBJMKWm3N76t0wJM2cl23DsOyaCRs5X 8Mw9DcPvZCKc8kXV5iX/VehHPUc65WiuX09Nmve2qTZKNDEewhSlH2QGH4C6pcIAyEDF EBWsgzH3DyweVo3zmh3Hhu7iYq7MJvPr97Q5wxPtHBFYezIP3BsApDMnhZVN4GKe3fFN HDN3DA6UMYFOsKXoIsXQYpHmXE0XdKQReiPEeXBte/ItJcJ2Fa11nCkyX94wtEN0FtsE P2DJVaif8vxKbwpAuc9MUzcFTntQmESfC0kJR33Q5sQBLm9P5c6Wtj4jqT2B90SH47qC 7rrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SeGlG3ooT8T8szI81EK2LLLSBaO8vVI8uYji8Z3GIks=; b=YNd5CAL0GSArR+Ew8bsn2zkIbUZwaxBrLRwBWg18g2Ks8SYxf7+Gdz0QRcpBeLJPNr 1McxD8OSfvg6Xt8kqLfrG6YC5dITYuclBGKn1JUacO6ddStv6U5LbEr9QXfiQulRrAQv pgIHH0WMTR2nWJ3tQwXjjYmEbdwpS+GBsP6aZiHqqIqt4DL774vv7pQmCe78TeKkX25O YaIFIviW8JXLs5kE+SJVeKyk9Iz65+KmNBYLEUDJa2NXX6dQh589E0XsADqVmiNJOLvG UPwq659zcD/A2YIsNMdcVBAflKgMA07zZ+Y7UYLW6Fjzz1CL61OJSQ8jQMpCEYzkoAc7 ZBzQ== X-Gm-Message-State: AElRT7GM1++IJBU5mv8u1BPnkmix770/5WRopLd3vnPRV366KwZi400B lUhd+mkn6BI9+MWdphN+HFQcYTLlNTi2dhredYk= X-Google-Smtp-Source: AG47ELsDNRXeYk1DogHGU4C2re+CaWYTrAdwg2CUQLkQr02QVgGluokGahHlCZGmT2qJw1Y1o74ZG3d39s4hzRLnaE0= X-Received: by 10.159.60.89 with SMTP id w25mr273819uah.59.1520943957657; Tue, 13 Mar 2018 05:25:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rick Miller Date: Tue, 13 Mar 2018 12:25:47 +0000 Message-ID: Subject: Re: FreeBSD 11.x fails to boot w/ SAS3 4Kn HDD and LSISAS3008 on SuperMicro X10DRH-iT To: FreeBSD Questions , freebsd-geom@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 12:25:59 -0000 As it turns out, it seems EFI must be specified as the boot environment as opposed to legacy or BIOS+EFI. Setting the boot environment to EFI only resulted in successful system boot. Thanks for the replies. The answer came from Allan Jude on Twitter. On Mon, Mar 12, 2018 at 6:18 PM Rick Miller wrote: > Hi all, > > Thanks in advance to anyone that might be able to help. I subscribed to > freebsd-geom@ so that the list did not need to "reply-all". Having > trouble getting FreeBSD 11-STABLE @ r329011 to boot from SAS3 4Kn HDDs via > LSISAS 3008 HBA on a SuperMicro X10DRH-iT motherboard after an apparent > installation. All internal media (including all other disks attached to the > HBA) were removed to eliminate other storage being the reason the system > won't boot. This occurs specifically in CSM mode, but the preference is to > boot via UEFI mode instead. > > Anyway...booting the machine via the memstick image demonstrates the > LSISAS 3008 controller attaching via mpr(4) (whose manpage describes the > controller being supported[1]): > > mpr0@pci0:3:0:0: class=0x010700 card=0x080815d9 chip=0x00971000 rev=0x02 > hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = 'SAS3008 PCI-Express Fusion-MPT SAS-3' > class = mass storage > subclass = SAS > > The only inserted disk attaches as da0 as illustrated by dmesg: > > ses0: pass0,da0: Elemne t descriptor: 'Slot00' > da0 at mpr0 bus 0 scbus0 target 8 lun 0 > ses0: pass0,da0: SAS Device Slot Element: 1 Phys at Slot 0 > ses0: phy 0: SAS device type 1 id 0 > ses0: phy 0: protocols: initiator( None ) Target( SSP ) > ses0: phy 0: parent 500304801e870bff addr 5000c500a012814d > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number $serial_number > da0: 1200.000MB/s transfers > da0: Command queueing enabled > da0: 1907729MB (488378648 4096 byte sectors) > > The original goal was to boot via zfs root, but when that failed, > subsequent installations used the "Auto (UFS) option" to partition the > disk. For example, the first installation gpart'd the disk as: > > # gpart show da0 > => 6 488378635 da0 GPT (1.8T) > 6 128 1 freebsd-boot (512K) > 134 487325568 2 freebsd-ufs (1.8T) > 487325702 1048576 3 freebsd-swap (4.0G) > 488374278 4363 - free - (17M) > > The result was a reboot loop. When the system reached the point of reading > the disk, it just rebooted and continued doing so. There was no loader or > beastie menu. Thus, thinking that it could be the partition layout > requirements of the 4Kn disks, it was gpart'd like the below[2][3]. This > was done by exiting to the shell during the partition phase of bsdinstall > and manually gpart'ing the disk according to the below, mounting da0p2 at > /mnt and placing an fstab at /tmp/bsdinstall_etc/fstab that included mount > entries for /dev/da0p2 at / and /dev/da0p3 as swap. > > # gpart show da0 > => 6 488378635 da0 GPT (1.8T) > 6 34 - free - (136K) > 40 512 1 freebsd-boot (2.0M) > 552 419430400 2 freebsd-ufs (1.6T) > 419430952 1048576 3 freebsd-swap (4.0G) > 420479528 67899113 - free - (259G) > > When configured as such, the system rebooted at the completion of the > install and appeared to roll through the boot order, which specifies the > HDD first, then CD/DVD, then network. It did attempt to boot via network, > but is irrelevant here. > > All the hardware is alleged to be supported by FreeBSD as best I can tell > and OS installation apparently works. I'm at a loss as to why the OS won't > boot. Does someone have feedback or input that may expose why it doesn't > boot? > > FWIW, a RHEL7 install was also attempted, which also does not boot. > > [1] > https://www.freebsd.org/cgi/man.cgi?query=mpr&apropos=0&sektion=4&manpath=FreeBSD+11.1-RELEASE&arch=default&format=html > [2] > https://lists.freebsd.org/pipermail/freebsd-hardware/2013-September/007380.html > [3] http://www.wonkity.com/~wblock/docs/html/disksetup.html > > -- > Take care > Rick Miller > -- Take care Rick Miller From owner-freebsd-stable@freebsd.org Tue Mar 13 16:20:51 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 763C7F2D4AF for ; Tue, 13 Mar 2018 16:20:51 +0000 (UTC) (envelope-from Albert.Shih@obspm.fr) Received: from mx-p1.obspm.fr (mx-p1.obspm.fr [145.238.193.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.obspm.fr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05D2D85F44 for ; Tue, 13 Mar 2018 16:20:50 +0000 (UTC) (envelope-from Albert.Shih@obspm.fr) Received: from io.chezmoi.fr (io-p2.obspm.fr [145.238.197.205]) (authenticated bits=0) by mx-p1.obspm.fr (8.14.4/8.14.4/DIO Observatoire de Paris - 15/04/10) with ESMTP id w2DGFoWV228612 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Mar 2018 17:15:51 +0100 Date: Tue, 13 Mar 2018 17:15:53 +0100 From: Albert Shih To: freebsd-stable@freebsd.org Subject: FreeBSD 11.1,11-stable,12-current on Dell H740p raid Message-ID: <20180313161553.GC8462@io.chezmoi.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.4 (2018-02-28) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (mx-p1.obspm.fr [145.238.193.20]); Tue, 13 Mar 2018 17:15:51 +0100 (CET) X-Virus-Scanned: clamav-milter 0.99.3 at mx-p1.obspm.fr X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 16:20:51 -0000 Hi, I got issue with Dell PowerEdge R740/R640 server with H740p and FreeBSD 11.1-Release, 11-stable, 12-current In all version I don't able to find the raid controler, so no disk...so of course impossible to install anything. I don't know if it's the right mailing-list, but if they are someone can help.... In other way, I can do « any » test for making thing work and help the freebsd team. Because Dell are still a large provider for hardware, and that would be very sad if FreeBSD cannot run on Dell. I still got some time (~ 1 month) before the server go in to production. For information Debian with Linux kernel prio to 4.14 don't work either. Currently only RedHat 7 work out of the box. Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France xmpp: jas@obspm.fr Heure local/Local time: Tue Mar 13 17:10:42 CET 2018 From owner-freebsd-stable@freebsd.org Tue Mar 13 16:36:42 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35630F30156 for ; Tue, 13 Mar 2018 16:36:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79E8B87ADD for ; Tue, 13 Mar 2018 16:36:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1evmuc-000Oen-AQ for freebsd-stable@freebsd.org; Tue, 13 Mar 2018 18:36:30 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: annoying panic on boot Message-Id: Date: Tue, 13 Mar 2018 18:36:30 +0200 To: freebsd-stable X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 16:36:42 -0000 Stopped at vga_bitblt_one_text_pixels_block+0x13e: movl = (%rax,%r13,4),%d db> bt =20 Tracing pid 4 tid 100090 td 0xfffff8000c522620 vga_bitblt_one_text_pixels_block() at = vga_bitblt_one_text_pixels_block+0x13e/fr0 vga_bitblt_text() at vga_bitblt_text+0xc0/frame 0xfffffe00002d5160 vt_flush() at vt_flush+0x38f/frame 0xfffffe00002d51b0 termcn_cnputc() at termcn_cnputc+0xbe/frame 0xfffffe00002d51e0 cnputc() at cnputc+0x181/frame 0xfffffe00002d5210 cnputs() at cnputs+0x78/frame 0xfffffe00002d5230 putchar() at putchar+0x14d/frame 0xfffffe00002d52b0 kvprintf() at kvprintf+0x113d/frame 0xfffffe00002d53b0 vprintf() at vprintf+0x84/frame 0xfffffe00002d5500 printf() at printf+0x43/frame 0xfffffe00002d5560 cddone() at cddone+0x210/frame 0xfffffe00002d5b20 xpt_done_process() at xpt_done_process+0x697/frame 0xfffffe00002d5b60 xpt_done_td() at xpt_done_td+0x196/frame 0xfffffe00002d5bb0 fork_exit() at fork_exit+0x82/frame 0xfffffe00002d5bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00002d5bf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 =E2=80=94 the above happens on boot, sometimes, the host is a dell PowerEdge R710 = running very resent stable, any help? thanks, danny= From owner-freebsd-stable@freebsd.org Tue Mar 13 16:52:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C2BEF316C0 for ; Tue, 13 Mar 2018 16:52:17 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C52A068883 for ; Tue, 13 Mar 2018 16:52:16 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1evn9r-00091D-CT; Tue, 13 Mar 2018 16:52:15 +0000 Date: Tue, 13 Mar 2018 16:52:15 +0000 From: Gary Palmer To: Albert Shih Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 11.1,11-stable,12-current on Dell H740p raid Message-ID: <20180313165215.GA59700@in-addr.com> References: <20180313161553.GC8462@io.chezmoi.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313161553.GC8462@io.chezmoi.fr> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 16:52:17 -0000 On Tue, Mar 13, 2018 at 05:15:53PM +0100, Albert Shih wrote: > Hi, > > > I got issue with Dell PowerEdge R740/R640 server with H740p and FreeBSD > 11.1-Release, 11-stable, 12-current > > In all version I don't able to find the raid controler, so no disk...so of > course impossible to install anything. > > I don't know if it's the right mailing-list, but if they are someone can > help.... > > In other way, I can do ? any ? test for making thing work and help the > freebsd team. Because Dell are still a large provider for hardware, and that would > be very sad if FreeBSD cannot run on Dell. > > I still got some time (~ 1 month) before the server go in to production. > > For information Debian with Linux kernel prio to 4.14 don't work either. Currently only > RedHat 7 work out of the box. Download the driver from https://www.broadcom.com/products/storage/raid-controllers/megaraid-9460-8i#downloads and try that. Regards, Gary From owner-freebsd-stable@freebsd.org Fri Mar 16 16:44:50 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E7D0F5CD4A; Fri, 16 Mar 2018 16:44:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED7E268A27; Fri, 16 Mar 2018 16:44:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 857B12603AE; Fri, 16 Mar 2018 17:44:47 +0100 (CET) Subject: Re: [HEADS UP] - OFED/RDMA stack update To: Konstantin Belousov , Navdeep Parhar Cc: "'freebsd-infiniband@freebsd.org'" , freebsd-drivers , Meny Yossefi , "'FreeBSD-stable@FreeBSD.org'" , freebsd-arch References: <1519683699.47932.5.camel@FreeBSD.org> <20180226224311.GT94212@kib.kiev.ua> From: Hans Petter Selasky Message-ID: <3027f48e-0ba8-555d-df23-d638303cb125@selasky.org> Date: Fri, 16 Mar 2018 17:44:41 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180226224311.GT94212@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 16:44:50 -0000 Hi, The bsd_rdma_4_9_stable_11 projects branch is close to being merged into FreeBSD 11-stable. Mellanox plans to merge no later than 12:00 CEST TUE 20th of March 2018, unless objections are received. A compatibility header file has been created, ib_verbs_compat.h, which offers full source compatibility to existing OFED kernel applications, as a response to the raised conserns. User-space compatibility is maintained through library symbol versioning. https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/ofed/include/rdma/ib_verbs_compat.h An example client for this header file can be found here: https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/contrib/rdma/krping_compat/ Currently the cxgb and cxgbe i-Warp drivers are not building, and will be stubbed from the kernel build before the branch is merged, unless Chelsio can add patches for these. Here is a quick and dirty patch to make the bsd_rdma_4_9_stable_11 branch build: > diff --git a/sys/modules/Makefile b/sys/modules/Makefile > index 6b005c854d7..b918a208f21 100644 > --- a/sys/modules/Makefile > +++ b/sys/modules/Makefile > @@ -530,7 +530,7 @@ _txp= txp > .if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \ > ${MACHINE_ARCH:C/mips(el)?/mips/} != "mips" && \ > ${MACHINE_ARCH} != "powerpc" && ${MACHINE_CPUARCH} != "riscv" > -_cxgbe= cxgbe > +#_cxgbe= cxgbe > .endif > > .if ${MK_TESTS} != "no" || defined(ALL_MODULES) > @@ -554,7 +554,7 @@ _vpo= vpo > _sym= sym > # intr_disable() is a macro, causes problems > .if ${MK_SOURCELESS_UCODE} != "no" > -_cxgb= cxgb > +#_cxgb= cxgb > .endif > .endif --HPS From owner-freebsd-stable@freebsd.org Sat Mar 17 18:01:23 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09A3BF5CED2 for ; Sat, 17 Mar 2018 18:01:23 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9597A87429 for ; Sat, 17 Mar 2018 18:01:22 +0000 (UTC) (envelope-from nimrod@nimrod.is-a-geek.net) Received: by mail-yw0-x236.google.com with SMTP id l200so9062301ywb.0 for ; Sat, 17 Mar 2018 11:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XkbX/jfqc9p1c/3m1aanmaUttuJegrSbnrCQq6NXxaU=; b=ZcuU+EevlgyO9sv5zr7wwnPyYX4JpkjjSb4ny2crzKgyey3zbHcKDtSvDmnOMQC1BZ Vkpst4a3Gf1Pi6qUyMeKWzx7RCA079ICx4xmEH4KmERo8P6evm/pbqN/rmOU4Gn7UIUB C0iktEPZw7lvs0VHtQ3Adu9TgvjWl58JF92IX4Wl61v5mWORf7AuL4/4rM4i4Aml4uyM Yue468JOwdNDZkhW7GdCv5CaRrPpjE7o1QdnBC7p4i7EXfmNMOOsLP3zT3ccP41Z2bPM DWy2xgHlRjTIVMuuw57b3z/oO+QWJA09jNgMnrZs6jHexAtEr1ZLjRIqcVLV59I+UKTn Tsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XkbX/jfqc9p1c/3m1aanmaUttuJegrSbnrCQq6NXxaU=; b=H1+Ugl1Fy3AL83TcxmnqFKDE+U2uUyC3zf3/lgmCd3zI8OHKWoxKt2Bq6hAB7ajMGc pi4mBXZ0RkQlXiAPacU02sHHgC8y3cm+erLZp4G0bWACgek/mqNUOB1Vw742Xz2ZlJ8+ Th7qX1RjpPMaZN8Ap62112ZAWZKxAJGaSSuwPy75XKQ7VQt9f1s2B3toxe5mlPEDuH87 lmYmW1UEkIuEewhjwvrD34wKf4BCFfoHbUJHs6/HjPaxIMsBJcLXWDMZbHsxOzTDUUBc nFkv0/wOD3Ez1QocloYD5Dw5dl6kmCRixthEZm+GEbWsV8YSY0vmimZwwgs+sTcDWTmV Kt8g== X-Gm-Message-State: AElRT7Gqq6TPAwWpXhWm4e4hRSSsaugry7fob3r43ylgmMIxl+rWWh/N zWFVSZgppQfWTpVSdm1zHK0S26Vpabz2Zy4+9QG1fQ== X-Google-Smtp-Source: AG47ELtrdQeH9/8l+j7ymtbsb1kQljbuynGCm1Pl5nixOW0YTmag/qdzGAjjS4T50VlCe6+aGzcyhaY1mGWNdSIaa84= X-Received: by 2002:a25:2387:: with SMTP id j129-v6mr3689622ybj.375.1521309681343; Sat, 17 Mar 2018 11:01:21 -0700 (PDT) MIME-Version: 1.0 References: <92a60e14-f532-2647-d45d-b500fc59ba88@sentex.net> <425be16f-9fdc-9ed6-72b1-02e28bfd130f@sentex.net> In-Reply-To: From: Nimrod Levy Date: Sat, 17 Mar 2018 18:01:10 +0000 Message-ID: Subject: Re: Ryzen lockup on bhyve was (Re: new Ryzen lockup issue ?) To: Mike Tancsa Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 18:01:23 -0000 Looks like I got almost 4 full weeks before it locked up this morning :( On Fri, Feb 23, 2018 at 3:33 PM Nimrod Levy wrote: > After a couple of hours of running the iperf commands you were testing > with, I'm unable to duplicate this so far. > > I'm running with FreeBSD stable from 17-Feb with the commits noted in > https://reviews.freebsd.org/D14347 pulled in. > > I've also lowered the memory clock and disabled c-states in the bios. > > The bhyve VM is running CentOS. > > The system has been up for over 6 days and has been running the iperf3 > loop for over 2 hours. > > The hardware is an Asus prime B350-Plus with a Ryzen 5 1600 and 32G of RAM. > > -- > Nimrod > > > On Fri, Feb 23, 2018 at 3:22 PM, Mike Tancsa wrote: > >> Actually I can confirm the same sort of hard lockup happens on my Epyc >> board with RELENG11. It also happens in current. I will file a PR and >> post on freebsd-current in case someone has any suggestions on how to >> try and figure out whats going on. >> >> I upgraded the box to >> 12.0-CURRENT #0 r329866 >> in order to see if it could avoid the lockup, but same deal. The vmm >> driver does seem different when loaded, but the same lock up under load >> >> CPU: AMD Ryzen 5 1600X Six-Core Processor (3593.35-MHz >> K8-class CPU) >> Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 >> >> >> Features=0x178bfbff >> >> >> Features2=0x7ed8320b >> AMD Features=0x2e500800 >> AMD >> >> Features2=0x35c233ff >> Structured Extended >> >> Features=0x209c01a9 >> XSAVE Features=0xf >> AMD Extended Feature Extensions ID EBX=0x7 >> SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 >> TSC: P-state invariant, performance statistics >> >> >> AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0 >> driver bug: Unable to set devclass (class: ppc devname: (unknown)) >> ivhd0: on acpi0 >> ivhd0: Flag:b0 >> ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0 >> ivhd0: Extended features[31:0]:22294ada HATS = >> 0x2 GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 >> DualPortLogSup = 0x2 DualEventLogSup = 0x2 >> ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f >> DevTblSegSup = 0x3 MarcSup = 0x1 >> ivhd0: supported paging level:7, will use only: 4 >> ivhd0: device range: 0x0 - 0xffff >> ivhd0: PCI cap 0x190b640f@0x40 feature:19 >> >> >> >> On 2/23/2018 12:35 PM, Nimrod Levy wrote: >> > Now that is a fascinating data point. My machine that I've been having >> > issues with has been running a bhyve vm from the beginning. I never >> > made the connection. I'll try throwing some network traffic at the VM >> > and see if I can make it lock up. >> > >> > On Fri, Feb 23, 2018 at 10:14 AM, Mike Tancsa > > > wrote: >> > >> > On 2/22/2018 3:41 PM, Mike Tancsa wrote: >> > > On 2/21/2018 3:04 PM, Mike Tancsa wrote: >> > >> Not sure if I have found another issue specific to Ryzen, or a >> bug that >> > >> manifests itself on Ryzen systems easier. I installed the latest >> > >> virtualbox from the ports and was doing some network performance >> tests >> > >> between a vm and the hypervisor using iperf3. The guest is just >> a >> > >> RELENG11 image and the network is an em nic bridged to epair1b >> > > >> > > This looks possibly related to VirtualBox. Doing the same tests >> and more >> > > using bhyve, I dont get any lockup. Not to mention, network IO >> is MUCH >> > > faster. >> > >> > >> > Actually, it just took a little bit longer to lock up the box with >> bhyve >> > on RELENG_11 as the hypervisor. Would be great if anyone can >> confirm >> > this locks up their Ryzen boxes ? I tried 2 different boxes to >> eliminate >> > a hardware issue. Also tried a similar test on Ubuntu and I can >> spin up >> > 4 instances and run without lockups. >> > >> > Just grab a copy of >> > >> > >> https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-RELEASE/amd64/Latest/FreeBSD-11.1-RELEASE-amd64.raw.xz >> > < >> https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-RELEASE/amd64/Latest/FreeBSD-11.1-RELEASE-amd64.raw.xz >> > >> > >> > and make 2 copies. tmp.raw and tmp2.raw >> > >> > >> > kldload vmm >> > ifconfig tap0 create >> > ifconfig tap1 create >> > ifconfig tap1 up >> > ifconfig tap0 up >> > ifconfig bridge0 create addm tap0 addm tap1 >> > ifconfig bridge0 192.168.99.1/24 >> > >> > screen -d -m sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 6144M -t >> tap0 >> > -d tmp.raw BSD11a >> > screen -d -m sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 6144M -t >> tap1 >> > -d tmp2.raw BSD11b >> > >> > Install netperf on the 2 vms and give the vtnet interface >> > 192.168.99.2/24 and 192.168.99.3/24 >> > >> > >> > In both VMs pkg install iperf3 and start it up as >> > iperf -s >> > >> > In the hypervisor, >> > iperf -t 10000 -R -c 192.168.99.2 >> > iperf -t 10000 -c 192.168.99.3 >> > >> > >> > the box locks up solid after 5-20 min. Same hardware with Ubuntu >> and >> > virtual box and 4 instances work fine, no lockups after a day so not >> > sure whats up but it seems to be something with the Ryzen CPU >> running as >> > a hypervisor or with some type of load :( >> > >> > Prior to lockup I had a stream of netstat -m writing to a file >> every 5 >> > seconds. The last entry was below. It doesnt seem to be leak. >> > >> > Thu Feb 22 17:14:28 EST 2018 >> > 8694/10281/18975 mbufs in use (current/cache/total) >> > 8225/5211/13436/2038424 mbuf clusters in use >> (current/cache/total/max) >> > 8225/5184 mbuf+clusters out of packet secondary zone in use >> > (current/cache) >> > 461/3747/4208/1019211 4k (page size) jumbo clusters in use >> > (current/cache/total/max) >> > 0/0/0/301988 9k jumbo clusters in use (current/cache/total/max) >> > 0/0/0/169868 16k jumbo clusters in use (current/cache/total/max) >> > 20467K/27980K/48447K bytes allocated to network >> (current/cache/total) >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> > 0 sendfile syscalls >> > 0 sendfile syscalls completed without I/O request >> > 0 requests for I/O initiated by sendfile >> > 0 pages read by sendfile as part of a request >> > 0 pages were valid at time of a sendfile request >> > 0 pages were requested for read ahead by applications >> > 0 pages were read ahead by sendfile >> > 0 times sendfile encountered an already busy page >> > 0 requests for sfbufs denied >> > 0 requests for sfbufs delayed >> > >> > >> > >> > ---Mike >> > >> > >> > >> > >> > -- >> > ------------------- >> > Mike Tancsa, tel +1 519 651 3400 x203 <(519)%20651-3400> >> > >> > Sentex Communications, mike@sentex.net >> > Providing Internet services since 1994 www.sentex.net >> > >> > Cambridge, Ontario Canada >> > _______________________________________________ >> > freebsd-stable@freebsd.org >> > mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > >> > To unsubscribe, send any mail to >> > "freebsd-stable-unsubscribe@freebsd.org >> > " >> > >> > >> >> >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 x203 >> Sentex Communications, mike@sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada >> > > -- -- Nimrod From owner-freebsd-stable@freebsd.org Sat Mar 17 19:52:36 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF4D8F64340; Sat, 17 Mar 2018 19:52:35 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA6A6BD12; Sat, 17 Mar 2018 19:52:35 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pl0-x243.google.com with SMTP id m22-v6so7845160pls.5; Sat, 17 Mar 2018 12:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=WOzsTN7kJIZXhrUPU7HNhxhkX4eeYLTa2xaccMXJujQ=; b=BVZJ9zowhwLecc6zkDlWSd+Tq4NTIyuPncmeT3XTOwl+cVEdodCZcG8DywxQ2ir/qz XO0Bq6VGM5jpl9PcvzY832ZYq7rPgg+DqNbjvDPZn7Q61EJaueD8YaRDZJQXV1DZRC7g c8aOtZcSRWCNBeuNoH4q7P2BdMgfkQNrxLalyFfeJgeansfXshGJgO9ahP5BObes3pbF 5v3idzqy/sku37j1p5CvFK2WSMVtMCobMljtPmf41tgEO0j2PzCkXg0S9ylVUN2VG2w0 WzJWfbjAQR06GggY+4MQdkBjgb3fZWl7a9ETAB8TEdNqzGO8qkUDCovuXVQScvmypQ6V gCng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=WOzsTN7kJIZXhrUPU7HNhxhkX4eeYLTa2xaccMXJujQ=; b=cFPJAmt4cLcMDW1ZOhV/vtt2goyFYfiz7klzQ2GZo0l8VGi5xYEhbrh/bfuJ62xLJx JQkP6lumPIZ3o8Nmce4qP4oQb6BVXyCF+eNdiUcNLp6ZdRFRDBn0Ka5cwPWS0RNvx2dk MjnNXYXfEaDQamfzOwnbV4AUySBkH4fHBldBSSFbrhDitBfwruD1PDvFHO56jyYXcmYq 0lMzD/Bw+I5oDmHNeL1rYH6IagktqcfIi+HsAnBdbsBTFTkpezWPeYJbrMqoMi0aaIps pdHCK92QAfRyAOVsxvamY5Q79GuP97CRZWa6E+Uyg7LGkJJM87oNzD+e+d9v/ckyYlt2 mNfg== X-Gm-Message-State: AElRT7EWWf/w6LkpXZ+Hn4smSPrS6+4XaSs/tgQ9+Kdf2kqlL/ikLGaY EYD1kceNcfqef1/AjwR9908bfvNT X-Google-Smtp-Source: AG47ELs97s0plY6rCVbH/YAcdfo6b7Ua0WSTdAV0Skj5tzbDeuc1GwaXEoE4CENw1CdI/yo/MILccQ== X-Received: by 2002:a17:902:108a:: with SMTP id c10-v6mr1466917pla.22.1521316354379; Sat, 17 Mar 2018 12:52:34 -0700 (PDT) Received: from ox ([2601:641:c000:b800:c55e:d964:7a77:a05]) by smtp.gmail.com with ESMTPSA id v6sm20058516pfm.2.2018.03.17.12.52.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Mar 2018 12:52:33 -0700 (PDT) Sender: Navdeep Parhar Date: Sat, 17 Mar 2018 12:52:16 -0700 From: Navdeep Parhar To: Hans Petter Selasky Cc: Konstantin Belousov , "'freebsd-infiniband@freebsd.org'" , freebsd-drivers , Meny Yossefi , "'FreeBSD-stable@FreeBSD.org'" , freebsd-arch Subject: Re: [HEADS UP] - OFED/RDMA stack update Message-ID: <20180317195200.GA5223@ox> Mail-Followup-To: Hans Petter Selasky , Konstantin Belousov , "'freebsd-infiniband@freebsd.org'" , freebsd-drivers , Meny Yossefi , "'FreeBSD-stable@FreeBSD.org'" , freebsd-arch References: <1519683699.47932.5.camel@FreeBSD.org> <20180226224311.GT94212@kib.kiev.ua> <3027f48e-0ba8-555d-df23-d638303cb125@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3027f48e-0ba8-555d-df23-d638303cb125@selasky.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 19:52:36 -0000 Hold your horses. Do you have confirmation from the affected party that the shims are adequate for them? I have been waiting for that before looking at this branch. Is the iw_cxgbe breakage a simple merge conflict as previously discussed or do the shims require driver changes? If they don't then it should be possible to drop the iw_cxgbe from head into this branch and it should just work, is that correct? Regards, Navdeep On Fri, Mar 16, 2018 at 05:44:41PM +0100, Hans Petter Selasky wrote: > Hi, > > The bsd_rdma_4_9_stable_11 projects branch is close to being merged into > FreeBSD 11-stable. Mellanox plans to merge no later than 12:00 CEST TUE 20th > of March 2018, unless objections are received. > > A compatibility header file has been created, ib_verbs_compat.h, which > offers full source compatibility to existing OFED kernel applications, as a > response to the raised conserns. User-space compatibility is maintained > through library symbol versioning. > > https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/ofed/include/rdma/ib_verbs_compat.h > > An example client for this header file can be found here: > > https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/contrib/rdma/krping_compat/ > > Currently the cxgb and cxgbe i-Warp drivers are not building, and will be > stubbed from the kernel build before the branch is merged, unless Chelsio > can add patches for these. > > Here is a quick and dirty patch to make the bsd_rdma_4_9_stable_11 branch > build: > > >diff --git a/sys/modules/Makefile b/sys/modules/Makefile > >index 6b005c854d7..b918a208f21 100644 > >--- a/sys/modules/Makefile > >+++ b/sys/modules/Makefile > >@@ -530,7 +530,7 @@ _txp= txp > > .if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \ > > ${MACHINE_ARCH:C/mips(el)?/mips/} != "mips" && \ > > ${MACHINE_ARCH} != "powerpc" && ${MACHINE_CPUARCH} != "riscv" > >-_cxgbe= cxgbe > >+#_cxgbe= cxgbe > > .endif > > .if ${MK_TESTS} != "no" || defined(ALL_MODULES) > >@@ -554,7 +554,7 @@ _vpo= vpo > > _sym= sym > > # intr_disable() is a macro, causes problems > > .if ${MK_SOURCELESS_UCODE} != "no" > >-_cxgb= cxgb > >+#_cxgb= cxgb > > .endif > > .endif > > --HPS From owner-freebsd-stable@freebsd.org Sat Mar 17 20:03:48 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 036A2F64F74; Sat, 17 Mar 2018 20:03:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9376C3DB; Sat, 17 Mar 2018 20:03:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 98064260370; Sat, 17 Mar 2018 21:03:45 +0100 (CET) Subject: Re: [HEADS UP] - OFED/RDMA stack update To: Konstantin Belousov , "'freebsd-infiniband@freebsd.org'" , freebsd-drivers , Meny Yossefi , "'FreeBSD-stable@FreeBSD.org'" , freebsd-arch References: <1519683699.47932.5.camel@FreeBSD.org> <20180226224311.GT94212@kib.kiev.ua> <3027f48e-0ba8-555d-df23-d638303cb125@selasky.org> <20180317195200.GA5223@ox> From: Hans Petter Selasky Message-ID: <6d451a3b-a635-08b1-f8d4-52fdc48083d6@selasky.org> Date: Sat, 17 Mar 2018 21:03:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180317195200.GA5223@ox> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 20:03:48 -0000 On 03/17/18 20:52, Navdeep Parhar wrote: > Hold your horses. Do you have confirmation from the affected party that > the shims are adequate for them? I have been waiting for that before > looking at this branch. Hi Navdeep, Mellanox has received an API list from at least one party, and has taken the action to support all the required APIs. > Is the iw_cxgbe breakage a simple merge conflict as previously discussed > or do the shims require driver changes? It is a merge conflict. The code already compiles in 12-current. > If they don't then it should be > possible to drop the iw_cxgbe from head into this branch and it should > just work, is that correct? Yes, it shouldn't be too hard to do and I would appreciate if Chelsio could throw some resources at this ASAP. I believe the new code will benefit everyone using Infiniband/RoCE and iWarp with FreeBSD. --HPS