From owner-freebsd-stable@freebsd.org Sun May 7 05:11:31 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97A28D62891 for ; Sun, 7 May 2017 05:11:31 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 51FF2136A for ; Sun, 7 May 2017 05:11:31 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-pg0-x22a.google.com with SMTP id o3so20021727pgn.2 for ; Sat, 06 May 2017 22:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=5E6vHFpu+BPHFnIJRPVMuAAm7VsBAMIyke4R8YYwGYw=; b=VA0d1n1Ta9ZFqAVmb0jmORolpxlIqUacCWh5iXzCVucA93TPZf6OrTh1rCtGgwRrMt wNY57ql9h4j8CpoNS62AJOWUc1I7fEX72XKQdLAgIMsQSNEMsT9dXBtYVabSlwlpL+Cf M993wswDhlyctoweYfA0M3PnyDqqZsVh6XZf4UNGaq4kb4AEwE9PLPJWYbPdft0VXr1B By/P0AuE5Eqsjvbst3lAvloKMO+/+3fBlQIM4awA4mC3TLwweK+6qbEj+m8qu8/TJztX +CMqjaE9OW5nERv4hom+48u/yKMhO4F3yxG8EtbA/+85H42jAfQs0HSLcniwzTjwVig5 jCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=5E6vHFpu+BPHFnIJRPVMuAAm7VsBAMIyke4R8YYwGYw=; b=BYORhwfbt/g50f9IsHAWHYRtMay5WvENiAQ1umqFrn/DF1YTesQyKeNQqhL6fPuF+5 3qzUPmrtVsGddfApzmxjvKBigaEYS2ca4vkdeinq9anvWSyRWAHyO5gRxVErPJgPt/nd tiWWxaeTxSRnYSI0t8tGlZoFsENq81Z44h5ihC0sJBDQwZH0HKqhLKJmzld/AyszE1nm dcG+Gq95GywHT79IzBTa0EuFM7c/DqaUTcTPy4GaoIjrkh/6Vn0o/ak1Uo5+DvB7hM2L GsgAGKzrx87g3y39j0ThzJaH2khPlQC/x0EDWdJkOCAlb3H/5Xd5xbPM9IjKXL81AUdU NBfA== X-Gm-Message-State: AN3rC/7vNjeAGwDW0SWGnU6mkkLZw2fcLDAZJYM/XqcVd8Es7hE2Hne7 ezh5TBDseaJdghVscrs= X-Received: by 10.84.218.205 with SMTP id g13mr59251257plm.38.1494133890645; Sat, 06 May 2017 22:11:30 -0700 (PDT) Received: from [192.168.88.254] (ip70-173-249-54.lv.lv.cox.net. [70.173.249.54]) by smtp.gmail.com with ESMTPSA id h71sm10034236pfe.85.2017.05.06.22.11.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 May 2017 22:11:29 -0700 (PDT) To: freebsd-stable@freebsd.org From: jungle boogie Subject: 11 stable vagrant images: page fault Message-ID: Date: Sat, 6 May 2017 22:11:28 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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.23 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, 07 May 2017 05:11:31 -0000 Hi All, I'm using 11-stable Vagrant image from here: https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-STABLE (tried 20th of April and 5th of April). Unfortunately, I can only get the VM to stay up for about 9 seconds, because it's in a constant reboot loop. This command will stop the reboot: VBoxManage setextradata stable_default_1494131864056_36337 "VBoxInternal/PDM/HaltOnReset" 1 And when doing so, I see this failure: http://imgur.com/a/USHdB I can download 11-stable and 12-current vdh files and import those into virtualbox, resulting in those not crashing. 11-stable is from the 20th of April. I also have this 12-current vagrant box working: vagrant@:~ % uname -a FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r316750: Thu Apr 13 08:03:28 UTC 2017 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 The host is some Unbuntu version: 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux VirtualBox is version 5.1.22 r115126, which is the most current version: https://www.virtualbox.org/wiki/Changelog Any thoughts? Thanks! From owner-freebsd-stable@freebsd.org Sun May 7 10:22:10 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02D78D628F8 for ; Sun, 7 May 2017 10:22:10 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C10241FB4 for ; Sun, 7 May 2017 10:22:09 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 9F209128672; Sun, 7 May 2017 10:21:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: 11 stable vagrant images: page fault From: Stefan Bethke In-Reply-To: Date: Sun, 7 May 2017 12:21:57 +0200 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: jungle boogie X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 07 May 2017 10:22:10 -0000 > Am 07.05.2017 um 07:11 schrieb jungle boogie = : >=20 > I'm using 11-stable Vagrant image from here: > https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-STABLE > (tried 20th of April and 5th of April). >=20 > Unfortunately, I can only get the VM to stay up for about 9 seconds, = because it's in a constant reboot loop. >=20 > This command will stop the reboot: > VBoxManage setextradata stable_default_1494131864056_36337 = "VBoxInternal/PDM/HaltOnReset" 1 >=20 > And when doing so, I see this failure: > http://imgur.com/a/USHdB >=20 > I can download 11-stable and 12-current vdh files and import those = into virtualbox, resulting in those not crashing. > 11-stable is from the 20th of April. Out of curiosity, can you try: = https://atlas.hashicorp.com/stblassitude/boxes/freebsd-11 I was unhappy with the official images, so I=E2=80=99m building my own. = On my Mac, I can run my image (including the latest freebsd-update = patches), without problems. The main difference in my image is that the freebsd-update patches are = already rolled into the image, so there=E2=80=99s no reboot cycle with = vagrant up. I=E2=80=99m updating the image every couple of weeks. The = packer config is at https://github.com/stblassitude/packer-freebsd Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@freebsd.org Sun May 7 16:01:11 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CC0FD6285C for ; Sun, 7 May 2017 16:01:11 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 509C91D56 for ; Sun, 7 May 2017 16:01:11 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-pg0-x22a.google.com with SMTP id u187so14932470pgb.0 for ; Sun, 07 May 2017 09:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3ITT3IMhMqfM/gD/y2tuxeB15zOpaiWvhs5Xu+qN3xk=; b=AM1NiF4y3hKNUSj5/0x8BHc5kPXSzax6skEpWydmJm/RH5XiWQ6t39r/GWyPiQ6wHK qXMWXVKS5wQ4c7hvjbPinsRbsVpBhVJYcq76pBwJ/9B+1gFpmxqFULVnZSd7qQDXgFuS KMMzQq5aSYKFtZpNFuVTKMjarBijYNVtdThL0JiutPm20727zfFGB3LQMJ3oHa8/uO1L kETnX0fYgU4y6ykjkhFjuq4ieDDoy3GgBn2EARwVgPM9m1q4oN9A3RO0IwikhfjlJRdY 8zAaCm3dBcwbu330PS8XUa6f208p8YIRwd9eXH0fyQf7NcTTIHV874+z4nZZgN1YthCe j/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3ITT3IMhMqfM/gD/y2tuxeB15zOpaiWvhs5Xu+qN3xk=; b=GzruUPTJP8rUnPHID3ZV2WFz7yTDCTD0DnUUOn3yFTg3PM4j0VvYOBlDzA8x07iHks RT86aBZ7vRKkA5FozD9ZVPWSpc99q2IY9HFvuZtfQuvj1zqmUZD7JO/XSPKwHqqwiYiM HRoSvzO0OH9n49nacuhCUNHD/bSEaFYNu0VS8+yQFroYN9o4+DM5WtoL+kOiji4XJjPx MFaaApEq634qentW7apc9rxjKzRLzEserGBnb5e1OB+s3ATrrRFidTeJDlJJ3o6qp7Ux 1z/W8tDJ9ZEOOukKP86BtajScqrD10P66ao6g2G7Y1viQmveBI0isueW38muBImvrifp ApmA== X-Gm-Message-State: AN3rC/6wYNvO3UL8oGJ8ul8tYyjqeR4zajgHzO8kmW/pAd6dw8nq9u1G KUb5n2F3oEhK0wzztpo= X-Received: by 10.84.174.1 with SMTP id q1mr60066707plb.188.1494172870313; Sun, 07 May 2017 09:01:10 -0700 (PDT) Received: from [192.168.88.254] (ip70-173-249-54.lv.lv.cox.net. [70.173.249.54]) by smtp.gmail.com with ESMTPSA id o5sm26091006pfk.126.2017.05.07.09.01.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 May 2017 09:01:09 -0700 (PDT) Subject: Re: 11 stable vagrant images: page fault To: Stefan Bethke References: Cc: freebsd-stable@freebsd.org From: jungle boogie Message-ID: <99591b41-40d2-d753-f2a6-db2c86f11af3@gmail.com> Date: Sun, 7 May 2017 09:01:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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.23 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, 07 May 2017 16:01:11 -0000 On 05/07/2017 03:21 AM, Stefan Bethke wrote: > >> Am 07.05.2017 um 07:11 schrieb jungle boogie : >> >> I'm using 11-stable Vagrant image from here: >> https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-STABLE >> (tried 20th of April and 5th of April). >> >> Unfortunately, I can only get the VM to stay up for about 9 seconds, because it's in a constant reboot loop. >> >> This command will stop the reboot: >> VBoxManage setextradata stable_default_1494131864056_36337 "VBoxInternal/PDM/HaltOnReset" 1 >> >> And when doing so, I see this failure: >> http://imgur.com/a/USHdB >> >> I can download 11-stable and 12-current vdh files and import those into virtualbox, resulting in those not crashing. >> 11-stable is from the 20th of April. > > Out of curiosity, can you try: https://atlas.hashicorp.com/stblassitude/boxes/freebsd-11 > Works! $ uname -a; freebsd-version -ku FreeBSD 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 11.0-RELEASE-p9 11.0-RELEASE-p10 So something is broken with those very specific 11-stable virtual machines. I went back to March and found one that works: FreeBSD 11.0-STABLE FreeBSD 11.0-STABLE #0 r315416: Thu Mar 16 17:20:57 UTC 2017 Very interesting the official image has been 'revoked': https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-RELEASE > I was unhappy with the official images, so I’m building my own. On my Mac, I can run my image (including the latest freebsd-update patches), without problems. > > The main difference in my image is that the freebsd-update patches are already rolled into the image, so there’s no reboot cycle with vagrant up. I’m updating the image every couple of weeks. > The packer config is at https://github.com/stblassitude/packer-freebsd Thanks, I'll check that out. I think a little more than a year ago there was a freeBSD journal article by Steve Willis or Brad Davis (I think!) about vagrant and packer. In addition to that article (if I still have it), do you have any reading material about vagrant/packer and making own images? > > > Stefan > From owner-freebsd-stable@freebsd.org Sun May 7 19:09:58 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 548DCD62056; Sun, 7 May 2017 19:09:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660073.outbound.protection.outlook.com [40.107.66.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C9F31FA1; Sun, 7 May 2017 19:09:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Sun, 7 May 2017 19:09:55 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1075.019; Sun, 7 May 2017 19:09:55 +0000 From: Rick Macklem To: Claude Buisson , FreeBSD Current CC: FreeBSD-STABLE Mailing List Subject: Re: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Topic: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Index: AQHSfJfpteLPu545NESwV/c/JyXxzaFUr0tBgJUhHQw= Date: Sun, 7 May 2017 19:09:54 +0000 Message-ID: References: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:QJnaxytj9O7EDznPmXE8HOVep80MZ8Il05EmLbPByAdAgyRXsA0DaUr9HokplMzYrvh+iPJwxKrCJD3X6XMGZPlYFMt0rhe/4z3LY6pxW0gozsKFtsh4Nl9SDsIPPVf7BdyzfqHt8vofeMEUfFLv74xbIKXcC7NKR+1eyDsZHkI+bHrmNCD2F3LSs8MRNPlCZH1jwKradWHtckafERGwFn6zrmPTibV4eem74nlpwDKU4gMl57fRsNnqfuwSmOKGgJg83/Nd/wm165MHmrSMKYZqPUh00or2llyoh/gU8dcemnVocuooj+NFbNj5wGROSxP3sq8PsTal/n4wuh5G6w== x-ms-office365-filtering-correlation-id: 2f4ac81c-e62f-42f9-6a43-08d4957ca574 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39400400002)(39840400002)(24454002)(8676002)(86362001)(7696004)(81166006)(2900100001)(478600001)(74316002)(33656002)(122556002)(305945005)(8936002)(38730400002)(2906002)(25786009)(4326008)(5660300001)(3660700001)(3280700002)(102836003)(6436002)(189998001)(53936002)(9686003)(55016002)(229853002)(50986999)(54356999)(76176999)(2950100002)(74482002)(6246003)(6506006)(77096006); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 07 May 2017 19:09:54.8717 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 07 May 2017 19:09:58 -0000 Claude Buisson wrote: >Hi, > >Last month, I started switching all my systems (stable/9, stable/10, >stable/11 and current) to NFSv4, and I found that: > > on current (svn 312652) an entry is added to /var/db/mounttab by >mount_nfs(8), but not suppressed by umount(8). It can be suppressed by >rpc.umntall(8). > >The same anomaly appears on stable/11 after upgrading to svn 312950. > >It is relatively easy to trace this anomaly to r308871 on current and >its MFHs (r309517 for stable/11). > >Patching sbin/umount/umount.c to restore the RPC call for NFSv4 makes >umount(8) suppress the mounttab entry as before. > >I do not know what is the proper solution, as suppressing the >modification of mounttab by mount_nfs(8) for NFSv4 could be an (more >complicated) alternative ! When I do an NFSv4 mount from a recent FreeBSD system, it does not use the Mount protocol. I am not sure why your NFSv4 mounts are putting an entry in mounttab, since that is done by mountd.c on the server and the client isn't= even contacting it? rick= From owner-freebsd-stable@freebsd.org Sun May 7 21:58:06 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDEFFD639A6 for ; Sun, 7 May 2017 21:58:06 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) by mx1.freebsd.org (Postfix) with ESMTP id 715891B9F for ; Sun, 7 May 2017 21:58:05 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([92.146.167.228]) by mwinf5d34 with ME id HZqQ1v00t4w07Zo03ZqRab; Sun, 07 May 2017 23:50:26 +0200 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Sun, 07 May 2017 23:50:26 +0200 X-ME-IP: 92.146.167.228 Subject: Re: Recent FreeBSD, NFSv4 and /var/db/mounttab To: Rick Macklem , FreeBSD Current References: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr> Cc: FreeBSD-STABLE Mailing List From: Claude Buisson Message-ID: <17039eeb-fd0d-a0f7-19bf-48c75013f222@orange.fr> Date: Sun, 7 May 2017 23:50:24 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 07 May 2017 21:58:07 -0000 On 05/07/2017 21:09, Rick Macklem wrote: > Claude Buisson wrote: >> Hi, >> >> Last month, I started switching all my systems (stable/9, stable/10, >> stable/11 and current) to NFSv4, and I found that: >> >> on current (svn 312652) an entry is added to /var/db/mounttab by >> mount_nfs(8), but not suppressed by umount(8). It can be suppressed by >> rpc.umntall(8). >> >> The same anomaly appears on stable/11 after upgrading to svn 312950. >> >> It is relatively easy to trace this anomaly to r308871 on current and >> its MFHs (r309517 for stable/11). >> >> Patching sbin/umount/umount.c to restore the RPC call for NFSv4 makes >> umount(8) suppress the mounttab entry as before. >> >> I do not know what is the proper solution, as suppressing the >> modification of mounttab by mount_nfs(8) for NFSv4 could be an (more >> complicated) alternative ! > When I do an NFSv4 mount from a recent FreeBSD system, it does not use the > Mount protocol. I am not sure why your NFSv4 mounts are putting an entry in > mounttab, since that is done by mountd.c on the server and the client isn't even > contacting it? > This is really an long delayed answer !! 1) I am afraid of a confusion on your side between mounttab which is managed on the CLIENT, and mountdtab which is managed of the SERVER. 2) Since my first mail, I patched mount_nfs(4) (client side) not to write an entry in mounttab in the NFS4 case. But: 3) I no more use NFS4 and have switched back to NFS3, sa as to have on the servers a trace of the current active clients by virtue of the mount protocol :-) > rick Thanks for your interest Claude Buisson From owner-freebsd-stable@freebsd.org Sun May 7 22:52:35 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7B72D62C92; Sun, 7 May 2017 22:52:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670069.outbound.protection.outlook.com [40.107.67.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 465F3F38; Sun, 7 May 2017 22:52:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Sun, 7 May 2017 22:52:32 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1075.019; Sun, 7 May 2017 22:52:32 +0000 From: Rick Macklem To: Claude Buisson , FreeBSD Current CC: FreeBSD-STABLE Mailing List Subject: Re: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Topic: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Index: AQHSfJfpteLPu545NESwV/c/JyXxzaFUr0tBgJUhHQyAAC5EAIAAD+VG Date: Sun, 7 May 2017 22:52:32 +0000 Message-ID: References: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr> , <17039eeb-fd0d-a0f7-19bf-48c75013f222@orange.fr> In-Reply-To: <17039eeb-fd0d-a0f7-19bf-48c75013f222@orange.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:+kT+CC1vAuM7atCG8YIYjf7/NDmSLiPSORehs1r/uMowV77XObebAjzgdO9OXXl88W640oRhZDtBA5WSBxu7DgsFERah3JjGbNw9/RKIj2oQdSyLV11W1KIiKOIL9bGA7hSB3kZeqhHFcfOkKRW5uTaOKLnyJ/gxpiOAvbv74GkNePrpa0disjch2Mo6UgmAaauID7xTCMIufut/L0XSoibvxGfi74KfNCp/rL/Eqaoz8waUHFi49JhtqjJtMzyozHyf84d31pqQJADQ8fFJGB1smb/djTJLX1vgRIlq42pLBz3hVGN6cdW/R51i2U3E+WyQ4HusxHyzUaUBNLQ8Ew== x-ms-office365-filtering-correlation-id: 9c2309d4-ab49-4bd4-540e-08d4959bbf53 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39410400002)(24454002)(53936002)(2950100002)(3280700002)(5660300001)(93886004)(305945005)(25786009)(7696004)(2906002)(9686003)(55016002)(122556002)(478600001)(3660700001)(74316002)(38730400002)(33656002)(74482002)(54356999)(6506006)(50986999)(76176999)(4326008)(6436002)(86362001)(229853002)(8936002)(8676002)(2900100001)(77096006)(81166006)(102836003)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 07 May 2017 22:52:32.7836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 07 May 2017 22:52:35 -0000 Claude Buisson wrote: [stuff snipped] > This is really an long delayed answer !! Just made it to the top of my "to do" list... > 1) I am afraid of a confusion on your side between mounttab which is > managed on the CLIENT, and mountdtab which is managed of the SERVER. Ok, now that I've looked, I see what you are talking about. To be honest, I= never knew this file even existed (it doesn't on the systems I run, since it has = never been created on them;-). > 2) Since my first mail, I patched mount_nfs(4) (client side) not to > write an entry in mounttab in the NFS4 case. But: Yes, I would say all that is needed is the call to add_mtab() in mount_nfs.= c be made conditional on a non-NFSv4 mount. Thanks for reporting this, rick From owner-freebsd-stable@freebsd.org Mon May 8 00:50:56 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AFD2D5F6B8; Mon, 8 May 2017 00:50:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670089.outbound.protection.outlook.com [40.107.67.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21B201474; Mon, 8 May 2017 00:50:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 00:50:53 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1075.019; Mon, 8 May 2017 00:50:53 +0000 From: Rick Macklem To: Claude Buisson , FreeBSD Current CC: FreeBSD-STABLE Mailing List Subject: Re: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Topic: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Index: AQHSfJfpteLPu545NESwV/c/JyXxzaFUr0tBgJUhHQyAAC5EAIAAMT4v Date: Mon, 8 May 2017 00:50:53 +0000 Message-ID: References: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr> , <17039eeb-fd0d-a0f7-19bf-48c75013f222@orange.fr> In-Reply-To: <17039eeb-fd0d-a0f7-19bf-48c75013f222@orange.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:lETvaxCVnBGsonJ4Ezxefxu2vzydJXXT3Rctiop5FGvLHj1eSBhWAIyvDMUqVKgBGchFekq3P39KiU/JNsowuoR4/P4APgw4lgHtSJuBHygmGpGcFg/5oh37RT330SO2GqJ1dNcRc9Z1/0b2I80LYWo1dOQFUw5iC3MbfyYA9pDN2dWwwrkKNKbnm2GdtoQqh+K4Vp2yK7oguvkhVRlUWrOT92pfLuKIx1dDm6Yx2wb36+jMlviZ9Fzsss4iv0SIbmK+F2o37MzDLYWhN853Ki4u6JHyLrKkJgHEmRUQspTEA9TH7W7nB+Q8D3PkWLz/c7i4mYzcGXN0Y9eci44zrA== x-ms-office365-filtering-correlation-id: ef7e6164-ff7e-44ad-ffab-08d495ac47d3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(24454002)(53936002)(2950100002)(3280700002)(305945005)(5660300001)(93886004)(25786009)(7696004)(2906002)(9686003)(55016002)(122556002)(478600001)(3660700001)(74316002)(38730400002)(33656002)(74482002)(54356999)(6506006)(50986999)(4326008)(76176999)(6436002)(86362001)(229853002)(8936002)(8676002)(2900100001)(77096006)(81166006)(102836003)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 08 May 2017 00:50:53.7134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 08 May 2017 00:50:56 -0000 Claude Buisson wrote: >On 05/07/2017 21:09, Rick Macklem wrote: >> Claude Buisson wrote: >>> Hi, >>> >>> Last month, I started switching all my systems (stable/9, stable/10, >>> stable/11 and current) to NFSv4, and I found that: >>> >>> on current (svn 312652) an entry is added to /var/db/mounttab by >>> mount_nfs(8), but not suppressed by umount(8). It can be suppressed by >>> rpc.umntall(8). >>> >>> The same anomaly appears on stable/11 after upgrading to svn 312950. >>> >>> It is relatively easy to trace this anomaly to r308871 on current and >>> its MFHs (r309517 for stable/11). >>> >>> Patching sbin/umount/umount.c to restore the RPC call for NFSv4 makes >>> umount(8) suppress the mounttab entry as before. >>> >>> I do not know what is the proper solution, as suppressing the >>> modification of mounttab by mount_nfs(8) for NFSv4 could be an (more >>> complicated) alternative ! I chose this alternative, since NFSv4 has nothing to do with the Mount prot= ocol. A one line patch to do this is now committed to head as r317931. Thanks for reporting this, rick [stuff snipped]= From owner-freebsd-stable@freebsd.org Mon May 8 13:43:33 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8FADD62BAE for ; Mon, 8 May 2017 13:43:33 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from borg.macktronics.com (gw.macktronics.com [209.181.253.70]) (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 4FFAAA48 for ; Mon, 8 May 2017 13:43:32 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from carob.macktronics.com (olive.macktronics.com [209.181.253.66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by borg.macktronics.com (Postfix) with ESMTPS id 5A74715D for ; Mon, 8 May 2017 08:38:20 -0500 (CDT) Date: Mon, 8 May 2017 08:38:19 -0500 (CDT) From: Dan Mack X-X-Sender: mack@localhost.local To: freebsd-stable@freebsd.org Subject: new 'make installworld' warnings Message-ID: User-Agent: Alpine 2.11 (GSO 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 08 May 2017 13:43:33 -0000 I buildworld / installworld a few times per week. I don't think I've ever seen these messages before: make[1]: "/usr/obj/usr/src/compiler-metadata.mk" line 1: Using cached compiler metadata from build at cow.example.com on Sun May 7 09:13:52 CDT 2017 make[3]: "/usr/obj/usr/src/compiler-metadata.mk" line 1: Using cached compiler metadata from build at cow.example.com on Sun May 7 09:13:52 CDT 2017 Possibly due to a significant enough deley between the run of buildworld and installworld? Build and install were otherwise successful. This happened when transitioning between 317440-stable -> 317906-stable Dan From owner-freebsd-stable@freebsd.org Mon May 8 15:42:29 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A262D62D4D for ; Mon, 8 May 2017 15:42:29 +0000 (UTC) (envelope-from hsr.hackspace@gmail.com) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 31BD91E53 for ; Mon, 8 May 2017 15:42:29 +0000 (UTC) (envelope-from hsr.hackspace@gmail.com) Received: by mail-ua0-x236.google.com with SMTP id z47so43971065uaz.0 for ; Mon, 08 May 2017 08:42:29 -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:cc; bh=UHmlObbm1rA/cST2HCSeywusLaGRFeNNMxiFaC2fseg=; b=bcE/WWSzQFmpxJtdcBGI5ZiEqNyFxrhKVGXm+VHNDterg7FWyjQt7KKk+doGwiId7d uSvMSv2m7L8xZ3i3jV88PJKvWLTtA/Y5+RkfKoD5QXzjb7XDd0pG+/eAGLKx7tekCccN cjOrNoKj/tS4Xb1f9L7Is/8rvCidfcJiU5J1O1HrLcXAynaqk9LNt00SgPtbfuXjorXs llvmnlZkZ+QgoFEAoWD+V0US4XyAeAfXU6qPQDHV3UmyaITUfujH+ugQ5XW8QAVYH4eC c54b+OEpFU049BK9+X6KANMCvyEKQZ+kPe1DJKWftx4mHrdlwIUwoYU9XELeujjuKCCL guBQ== 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:cc; bh=UHmlObbm1rA/cST2HCSeywusLaGRFeNNMxiFaC2fseg=; b=Ur2IPetPW6zIDIsnn5vofe8O7W85CpedqLAMbVytkVyrStDayYsM6jTpJUBJjFGxBJ JEzGT31Q05ccT+azGAqz+z/HPESfgrIXxvAYRGV0BCB2egBoUau5m4tbSe+VpjN1PtML L4moaEPzb1Krz7MYH8ABRKAUs1QPYjfOOEJcvRaDufUDe/JjH1CjLb1IvIIARwr18bbf OnqarhNNp2iKPkMX79wPEUvZm4jKjUcSlR3ldJ2cG2NgYkYkdVd8vL60/GP6/+irTiRB d5P2RqoYqmQmJxINgNk9P00ebuy3GO+0K6NexUbiA/VvS9mnEOycIL1EsKGM6EreGSoJ m3mw== X-Gm-Message-State: AN3rC/7W2i3AA2q4qCzEOFkkU3kh63kNWA41ojj656bXaDAZOCI5IZSS p2zTDrHC2s4PZZld1/tJ18zA4oU2xQ== X-Received: by 10.159.39.104 with SMTP id a95mr23345708uaa.94.1494258147959; Mon, 08 May 2017 08:42:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.244.66 with HTTP; Mon, 8 May 2017 08:42:27 -0700 (PDT) From: HSR Hackspace Date: Mon, 8 May 2017 21:12:27 +0530 Message-ID: Subject: Formatting a 4k disk on FreeBSD with ext2 To: freebsd-stable@freebsd.org Cc: "Theodore Ts'o" , Matthias Andree Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 08 May 2017 15:42:29 -0000 Hi folks; I'm trying to format a 300 GB partition on x86_64 box running running BSD 10.1 with HW RAID configuration. All my attempt so far have failed. Below are the logs for same. Logs: 1. pod1208-wsa07:rtestuser 106] ./mkfs.ext3 /dev/da0p7 mke2fs 1.43.4 (31-Jan-2017) Warning: could not erase sector 2: Invalid argument---------> Creating filesystem with 78643200 4k blocks and 19660800 inodes Filesystem UUID: c31fab56-f690-4313-a09c-9a585224caea Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 Allocating group tables: done Warning: could not read block 0: Invalid argument -----------> Warning: could not erase sector 0: Invalid argument Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: 0/2400 Warning, had trouble writing out superblocks. pod1208-wsa07:rtestuser 107] 2. pod1208-wsa07:rtestuser 32] ./fsck.ext2 -v -b 4096 /dev/da0p7 e2fsck 1.43.4 (31-Jan-2017) ./fsck.ext2: Invalid argument while trying to open /dev/da0p7 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 or e2fsck -b 32768 pod1208-wsa07:rtestuser 33] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3. pod1208-wsa07:rtestuser 43] ./dumpe2fs /dev/da0p7 dumpe2fs 1.43.4 (31-Jan-2017) ./dumpe2fs: Invalid argument while trying to open /dev/da0p7 Couldn't find valid filesystem superblock. pod1208-wsa07:rtestuser 44] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ pod1208-wsa07:rtestuser 29] ./mkfs.ext2 -b 4096 /dev/da0p7 mke2fs 1.43.4 (31-Jan-2017) Warning: could not erase sector 2: Invalid argument Creating filesystem with 78643200 4k blocks and 19660800 inodes Filesystem UUID: 015a85a4-7db9-4767-869c-7bab11c9074e Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 Allocating group tables: done Warning: could not read block 0: Invalid argument Warning: could not erase sector 0: Invalid argument Writing inode tables: done Writing superblocks and filesystem accounting information: 0/2400 Warning, had trouble writing out superblocks. pod1208-wsa07:rtestuser 30] 5. pod1208-wsa07:rtestuser 31] camcontrol identify da0 camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed pod1208-wsa07:rtestuser 32] 6. pod1208-wsa07:rtestuser 24] diskinfo -c da0 da0 4096 # sectorsize 1197995982848 # mediasize in bytes (1.1T) 292479488 # mediasize in sectors 0 # stripesize 0 # stripeoffset 18206 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. I/O command overhead: ^[OA time to read 10MB block 0.004811 sec = 0.000 msec/sector time to read 20480 sectors 0.491882 sec = 0.024 msec/sector calculated command overhead = 0.024 msec/sector pod1208-wsa07:rtestuser 25] diskinfo -c da0p7 da0p7 4096 # sectorsize 322122547200 # mediasize in bytes (300G) 78643200 # mediasize in sectors 0 # stripesize 1493762048 # stripeoffset 4895 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. I/O command overhead: time to read 10MB block 0.004860 sec = 0.000 msec/sector time to read 20480 sectors 0.495921 sec = 0.024 msec/sector calculated command overhead = 0.024 msec/sector 7. pod1208-wsa07:rtestuser 21] gpart show -l 6 292479477 da0 GPT (1.1T) 6 10 - free - (40K) 16 128 1 (null) (512K) 144 262144 2 efi (1.0G) 262288 1048576 3 rootfs (4.0G) 1310864 2097152 4 swap (8.0G) 3408016 1048576 5 nextroot (4.0G) 4456592 102400 6 var (400M) 4558992 78643200 7 raw (300G) 83202192 524288 8 godspeed (2.0G) 83726480 208752992 9 data (796G) 292479472 11 - free - (44K) Let me know if anyone have formatted 4k drive with ext2 recently. If yes from where should I start debugging this issue. Does above logs give hint on what could be going wrong here? TIA _SP On Mon, May 8, 2017 at 3:11 PM, HSR Hackspace wrote: > Sorry I used wrong device in above log. Below is correct data. > > > pod1208-wsa07:rtestuser 21] gpart show -l > => 6 292479477 da0 GPT (1.1T) > 6 10 - free - (40K) > 16 128 1 (null) (512K) > 144 262144 2 efi (1.0G) > 262288 1048576 3 rootfs (4.0G) > 1310864 2097152 4 swap (8.0G) > 3408016 1048576 5 nextroot (4.0G) > 4456592 102400 6 var (400M) > 4558992 78643200 7 raw (300G) > 83202192 524288 8 godspeed (2.0G) > 83726480 208752992 9 data (796G) > 292479472 11 - free - (44K) > > pod1208-wsa07:rtestuser 22] camcontrol identify da0p7 > camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed > cam_lookup_pass: No such file or directory > cam_lookup_pass: either the pass driver isn't in your kernel > cam_lookup_pass: or da0p7 doesn't exist > pod1208-wsa07:rtestuser 23] > pod1208-wsa07:rtestuser 23] > pod1208-wsa07:rtestuser 23] camcontrol identify da0 > camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed > pod1208-wsa07:rtestuser 24] > > > pod1208-wsa07:rtestuser 24] diskinfo -c da0 > da0 > 4096 # sectorsize > 1197995982848 # mediasize in bytes (1.1T) > 292479488 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 18206 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. > > I/O command overhead: > ^[OA time to read 10MB block 0.004811 sec = 0.000 msec/sector > time to read 20480 sectors 0.491882 sec = 0.024 msec/sector > calculated command overhead = 0.024 msec/sector > > pod1208-wsa07:rtestuser 25] diskinfo -c da0p7 > da0p7 > 4096 # sectorsize > 322122547200 # mediasize in bytes (300G) > 78643200 # mediasize in sectors > 0 # stripesize > 1493762048 # stripeoffset > 4895 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. > > I/O command overhead: > time to read 10MB block 0.004860 sec = 0.000 msec/sector > time to read 20480 sectors 0.495921 sec = 0.024 msec/sector > calculated command overhead = 0.024 msec/sector > > > -SP > > On Mon, May 8, 2017 at 11:31 AM, HSR Hackspace wrote: >> Hi Andree; >> >> Thanks for your prompt reply. Please find below the logs you requested. >> >> T & R >> _SP >> ++++++++++++++++++++++++++++++++++++++++++= >> pod1208-wsa07:rtestuser 4] diskinfo -c /dev/da0p7 >> /dev/da0p7 >> 4096 # sectorsize >> 322122547200 # mediasize in bytes (300G) >> 78643200 # mediasize in sectors >> 0 # stripesize >> 1493762048 # stripeoffset >> 4895 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >> >> I/O command overhead: >> time to read 10MB block 0.026713 sec = 0.001 msec/sector >> time to read 20480 sectors 0.494624 sec = 0.024 msec/sector >> calculated command overhead = 0.023 msec/sector >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> pod1208-wsa07:rtestuser 5] diskinfo -c /dev/da0 >> /dev/da0 >> 4096 # sectorsize >> 1197995982848 # mediasize in bytes (1.1T) >> 292479488 # mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> 18206 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >> >> I/O command overhead: >> time to read 10MB block 0.039394 sec = 0.002 msec/sector >> time to read 20480 sectors 0.485778 sec = 0.024 msec/sector >> calculated command overhead = 0.022 msec/sector >> >> pod1208-wsa07:rtestuser 6] >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> pod1208-wsa07:rtestuser 6] camcontrol identify da1 >> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed ----------------> >> cam_lookup_pass: No such file or directory >> cam_lookup_pass: either the pass driver isn't in your kernel >> cam_lookup_pass: or da1 doesn't exist >> pod1208-wsa07:rtestuser 7] >> >> >> >> >> >> On Sat, May 6, 2017 at 11:07 PM, Matthias Andree wrote: >>> Am 06.05.2017 um 16:47 schrieb Theodore Ts'o: >>>> On Fri, May 05, 2017 at 10:44:52PM +0530, HSR Hackspace wrote: >>>>> Thanks for prompt reply. I am sorry I forgot to mention that I am >>>>> doing all this on a FreeBSD 10.1 If you argument is till valid is >>>>> there anyway I confirm it? If HW raid is advertising 512 how is disk >>>>> info able to read correct data? >>>> Sorry, no clue. I don't really use FreeBSD myself. >>>> >>>> I've added Matthias to the cc list since he's the person who maintains >>>> e2fsprogs for the FreeBSD ports collection. I know how to fire up a >>>> FreeBSD VM on Google Compute Engine, and check to make sure e2fsprogs >>>> can build and pass the regression tests, but that is really the extent >>>> of my FreeBSD skills. >>>> >>>> Mattias --- the user is trying to create an ext2 file system on a >>>> hardware raid device which is using advanced format (4k sector) HDD's. >>>> >>>> The problem could be in libext2fs's attempt to find out the logical >>>> and physical sector size (we may not be using the right FreeBSD >>>> ioctl's to get that information), or it could be some bug in the >>>> Hardware Raid controller, or perhaps even in FreeBSD's handling of >>>> advanced format drives (although I really doubt that last). >>> >>> Greetings, >>> >>> I seem to recall that we pinged FreeBSD developers about getting the >>> physical, as opposed to the logical, block size of the device (a few >>> months ago), some disk/controller combinations exposing this via stripe >>> size, but there wasn't a consistent way of obtaining that at the time. >>> >>> Now, FreeBSD 10.1 has gone out of support, and we need kernel hacker >>> support here for the right ioctl()s. >>> I think the best approach is to ask the same question for FreeBSD 10.3 >>> and 11.0 and see what and how far we get. >>> >>> HSR, what do you get running camcontrol identify, and diskinfo, on your >>> disk? For example (replace da1 by your actual disk device): >>> >>> camcontrol identify da1 >>> >>> diskinfo da1 >>> >>> Best regards, >>> Matthias >>> From owner-freebsd-stable@freebsd.org Mon May 8 16:10:07 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACF5AD63B91 for ; Mon, 8 May 2017 16:10:07 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 10A7AB03 for ; Mon, 8 May 2017 16:10:06 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22e.google.com with SMTP id u65so90099124wmu.1 for ; Mon, 08 May 2017 09:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=S/CuxFSeXgbELbhazUNtdpY78z+EhSNn7B4/l//jajg=; b=DSrMm98oVmIxv2NSeXrUBV2bORqHVka46dWAlj91JtdrwyhUcXDkSQ09HcUXujl31j XGvlK2B45DJvuVEtJv5UcioiTqBvwtD/BvSzQpstoab1e5B9/M1hBheNRq0dMpO2A0Oy H1ZQHcjRf1YtFz2y3/sy/u2LskXXHphQIMEIttxg7HSSYQ14CyX+IMQTxukbLgQKuven JL7CrYOOjn0UiifRixjR33SDOeZdpEcra/QyT4CHAapt0dqaNGlKz6rztroVBgfL5ctu UqIZour6ZSV1hdr5j6gULJWc/wy+EYMAYd5oGAV4KMaR/mwOKg2h0uRtnZxyBB+LFt4P TOzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=S/CuxFSeXgbELbhazUNtdpY78z+EhSNn7B4/l//jajg=; b=LeU24ZLsMfUApF9FmM3l4cG7ET3sf1oEDLzUy2NKbOWzlfMcyRm3tJLaT6LarKkCMl Wi1OFoZbxh0Ufh3a4DDkYPIHjDc3Y2icH6E6uldfNjKLY9szMrydovuP01noj2kwZ+W0 coPupTFsHeD3GFsiuPsF9n06jRjfbTSxufDIyBZwEsy8YuJU52JYI/hk1XtIs/kKppN6 gLPjJlJI5Pjw2q29wV8OPpWts3J5nxiItqe3woqabF5EX5p/VcpJVw7Ri+OskLWfd7Dn iUV3FdOf3tvI6k2JD4Xy+Son1jpZDXRZLufpGudOeSGQb6Dp8YB2miuidWG4Yzu1lt0s MtSg== X-Gm-Message-State: AN3rC/46K8mUWp99Et4adqgjmmEb76uetLHrUSKhs+vjRBWqyEDxNNWH 0wVhs8tAYfuWVhN78rVPgg== X-Received: by 10.28.12.211 with SMTP id 202mr13155147wmm.32.1494259804591; Mon, 08 May 2017 09:10:04 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id c128sm10409488wmh.32.2017.05.08.09.10.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 09:10:03 -0700 (PDT) Subject: Re: Formatting a 4k disk on FreeBSD with ext2 To: freebsd-stable@freebsd.org References: From: Steven Hartland Message-ID: <6d8b1458-3f85-0e78-0e44-566f1a56d6fa@multiplay.co.uk> Date: Mon, 8 May 2017 17:10:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 08 May 2017 16:10:07 -0000 That looks like its trying to do an erase of the sectors, which is likely failing due to the device being a HW RAID, have you tried with nodiscard set? On 08/05/2017 16:42, HSR Hackspace wrote: > Hi folks; > > I'm trying to format a 300 GB partition on x86_64 box running running > BSD 10.1 with HW RAID configuration. All my attempt so far have > failed. Below are the logs for same. > > Logs: > > 1. pod1208-wsa07:rtestuser 106] ./mkfs.ext3 /dev/da0p7 > mke2fs 1.43.4 (31-Jan-2017) > Warning: could not erase sector 2: Invalid argument---------> > Creating filesystem with 78643200 4k blocks and 19660800 inodes > Filesystem UUID: c31fab56-f690-4313-a09c-9a585224caea > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 > > Allocating group tables: done > Warning: could not read block 0: Invalid argument -----------> > Warning: could not erase sector 0: Invalid argument > Writing inode tables: done > Creating journal (262144 blocks): done > Writing superblocks and filesystem accounting information: 0/2400 > Warning, had trouble writing out superblocks. > pod1208-wsa07:rtestuser 107] > > 2. > pod1208-wsa07:rtestuser 32] ./fsck.ext2 -v -b 4096 /dev/da0p7 > e2fsck 1.43.4 (31-Jan-2017) > ./fsck.ext2: Invalid argument while trying to open /dev/da0p7 > > The superblock could not be read or does not describe a valid ext2/ext3/ext4 > filesystem. If the device is valid and it really contains an ext2/ext3/ext4 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 > or > e2fsck -b 32768 > > pod1208-wsa07:rtestuser 33] > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 3. > pod1208-wsa07:rtestuser 43] ./dumpe2fs /dev/da0p7 > dumpe2fs 1.43.4 (31-Jan-2017) > ./dumpe2fs: Invalid argument while trying to open /dev/da0p7 > Couldn't find valid filesystem superblock. > pod1208-wsa07:rtestuser 44] > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 4. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > pod1208-wsa07:rtestuser 29] ./mkfs.ext2 -b 4096 /dev/da0p7 > mke2fs 1.43.4 (31-Jan-2017) > Warning: could not erase sector 2: Invalid argument > Creating filesystem with 78643200 4k blocks and 19660800 inodes > Filesystem UUID: 015a85a4-7db9-4767-869c-7bab11c9074e > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 > > Allocating group tables: done > Warning: could not read block 0: Invalid argument > Warning: could not erase sector 0: Invalid argument > Writing inode tables: done > Writing superblocks and filesystem accounting information: 0/2400 > Warning, had trouble writing out superblocks. > pod1208-wsa07:rtestuser 30] > > > 5. > pod1208-wsa07:rtestuser 31] camcontrol identify da0 > camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed > pod1208-wsa07:rtestuser 32] > > 6. > > pod1208-wsa07:rtestuser 24] diskinfo -c da0 > da0 > 4096 # sectorsize > 1197995982848 # mediasize in bytes (1.1T) > 292479488 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 18206 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. > > I/O command overhead: > ^[OA time to read 10MB block 0.004811 sec = 0.000 msec/sector > time to read 20480 sectors 0.491882 sec = 0.024 msec/sector > calculated command overhead = 0.024 msec/sector > > pod1208-wsa07:rtestuser 25] diskinfo -c da0p7 > da0p7 > 4096 # sectorsize > 322122547200 # mediasize in bytes (300G) > 78643200 # mediasize in sectors > 0 # stripesize > 1493762048 # stripeoffset > 4895 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. > > I/O command overhead: > time to read 10MB block 0.004860 sec = 0.000 msec/sector > time to read 20480 sectors 0.495921 sec = 0.024 msec/sector > calculated command overhead = 0.024 msec/sector > > 7. > pod1208-wsa07:rtestuser 21] gpart show -l > 6 292479477 da0 GPT (1.1T) > 6 10 - free - (40K) > 16 128 1 (null) (512K) > 144 262144 2 efi (1.0G) > 262288 1048576 3 rootfs (4.0G) > 1310864 2097152 4 swap (8.0G) > 3408016 1048576 5 nextroot (4.0G) > 4456592 102400 6 var (400M) > 4558992 78643200 7 raw (300G) > 83202192 524288 8 godspeed (2.0G) > 83726480 208752992 9 data (796G) > 292479472 11 - free - (44K) > > Let me know if anyone have formatted 4k drive with ext2 recently. If > yes from where should I start debugging this issue. Does above logs > give hint on what could be going wrong here? > > > TIA > _SP > > > On Mon, May 8, 2017 at 3:11 PM, HSR Hackspace wrote: >> Sorry I used wrong device in above log. Below is correct data. >> >> >> pod1208-wsa07:rtestuser 21] gpart show -l >> => 6 292479477 da0 GPT (1.1T) >> 6 10 - free - (40K) >> 16 128 1 (null) (512K) >> 144 262144 2 efi (1.0G) >> 262288 1048576 3 rootfs (4.0G) >> 1310864 2097152 4 swap (8.0G) >> 3408016 1048576 5 nextroot (4.0G) >> 4456592 102400 6 var (400M) >> 4558992 78643200 7 raw (300G) >> 83202192 524288 8 godspeed (2.0G) >> 83726480 208752992 9 data (796G) >> 292479472 11 - free - (44K) >> >> pod1208-wsa07:rtestuser 22] camcontrol identify da0p7 >> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >> cam_lookup_pass: No such file or directory >> cam_lookup_pass: either the pass driver isn't in your kernel >> cam_lookup_pass: or da0p7 doesn't exist >> pod1208-wsa07:rtestuser 23] >> pod1208-wsa07:rtestuser 23] >> pod1208-wsa07:rtestuser 23] camcontrol identify da0 >> camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed >> pod1208-wsa07:rtestuser 24] >> >> >> pod1208-wsa07:rtestuser 24] diskinfo -c da0 >> da0 >> 4096 # sectorsize >> 1197995982848 # mediasize in bytes (1.1T) >> 292479488 # mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> 18206 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >> >> I/O command overhead: >> ^[OA time to read 10MB block 0.004811 sec = 0.000 msec/sector >> time to read 20480 sectors 0.491882 sec = 0.024 msec/sector >> calculated command overhead = 0.024 msec/sector >> >> pod1208-wsa07:rtestuser 25] diskinfo -c da0p7 >> da0p7 >> 4096 # sectorsize >> 322122547200 # mediasize in bytes (300G) >> 78643200 # mediasize in sectors >> 0 # stripesize >> 1493762048 # stripeoffset >> 4895 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >> >> I/O command overhead: >> time to read 10MB block 0.004860 sec = 0.000 msec/sector >> time to read 20480 sectors 0.495921 sec = 0.024 msec/sector >> calculated command overhead = 0.024 msec/sector >> >> >> -SP >> >> On Mon, May 8, 2017 at 11:31 AM, HSR Hackspace wrote: >>> Hi Andree; >>> >>> Thanks for your prompt reply. Please find below the logs you requested. >>> >>> T & R >>> _SP >>> ++++++++++++++++++++++++++++++++++++++++++= >>> pod1208-wsa07:rtestuser 4] diskinfo -c /dev/da0p7 >>> /dev/da0p7 >>> 4096 # sectorsize >>> 322122547200 # mediasize in bytes (300G) >>> 78643200 # mediasize in sectors >>> 0 # stripesize >>> 1493762048 # stripeoffset >>> 4895 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >>> >>> I/O command overhead: >>> time to read 10MB block 0.026713 sec = 0.001 msec/sector >>> time to read 20480 sectors 0.494624 sec = 0.024 msec/sector >>> calculated command overhead = 0.023 msec/sector >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> pod1208-wsa07:rtestuser 5] diskinfo -c /dev/da0 >>> /dev/da0 >>> 4096 # sectorsize >>> 1197995982848 # mediasize in bytes (1.1T) >>> 292479488 # mediasize in sectors >>> 0 # stripesize >>> 0 # stripeoffset >>> 18206 # Cylinders according to firmware. >>> 255 # Heads according to firmware. >>> 63 # Sectors according to firmware. >>> 00ff273941fd086a1ec0fbb015e7a68d # Disk ident. >>> >>> I/O command overhead: >>> time to read 10MB block 0.039394 sec = 0.002 msec/sector >>> time to read 20480 sectors 0.485778 sec = 0.024 msec/sector >>> calculated command overhead = 0.022 msec/sector >>> >>> pod1208-wsa07:rtestuser 6] >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> pod1208-wsa07:rtestuser 6] camcontrol identify da1 >>> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed ----------------> >>> cam_lookup_pass: No such file or directory >>> cam_lookup_pass: either the pass driver isn't in your kernel >>> cam_lookup_pass: or da1 doesn't exist >>> pod1208-wsa07:rtestuser 7] >>> >>> >>> >>> >>> >>> On Sat, May 6, 2017 at 11:07 PM, Matthias Andree wrote: >>>> Am 06.05.2017 um 16:47 schrieb Theodore Ts'o: >>>>> On Fri, May 05, 2017 at 10:44:52PM +0530, HSR Hackspace wrote: >>>>>> Thanks for prompt reply. I am sorry I forgot to mention that I am >>>>>> doing all this on a FreeBSD 10.1 If you argument is till valid is >>>>>> there anyway I confirm it? If HW raid is advertising 512 how is disk >>>>>> info able to read correct data? >>>>> Sorry, no clue. I don't really use FreeBSD myself. >>>>> >>>>> I've added Matthias to the cc list since he's the person who maintains >>>>> e2fsprogs for the FreeBSD ports collection. I know how to fire up a >>>>> FreeBSD VM on Google Compute Engine, and check to make sure e2fsprogs >>>>> can build and pass the regression tests, but that is really the extent >>>>> of my FreeBSD skills. >>>>> >>>>> Mattias --- the user is trying to create an ext2 file system on a >>>>> hardware raid device which is using advanced format (4k sector) HDD's. >>>>> >>>>> The problem could be in libext2fs's attempt to find out the logical >>>>> and physical sector size (we may not be using the right FreeBSD >>>>> ioctl's to get that information), or it could be some bug in the >>>>> Hardware Raid controller, or perhaps even in FreeBSD's handling of >>>>> advanced format drives (although I really doubt that last). >>>> Greetings, >>>> >>>> I seem to recall that we pinged FreeBSD developers about getting the >>>> physical, as opposed to the logical, block size of the device (a few >>>> months ago), some disk/controller combinations exposing this via stripe >>>> size, but there wasn't a consistent way of obtaining that at the time. >>>> >>>> Now, FreeBSD 10.1 has gone out of support, and we need kernel hacker >>>> support here for the right ioctl()s. >>>> I think the best approach is to ask the same question for FreeBSD 10.3 >>>> and 11.0 and see what and how far we get. >>>> >>>> HSR, what do you get running camcontrol identify, and diskinfo, on your >>>> disk? For example (replace da1 by your actual disk device): >>>> >>>> camcontrol identify da1 >>>> >>>> diskinfo da1 >>>> >>>> Best regards, >>>> Matthias >>>> > _______________________________________________ > 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 May 9 20:10:19 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81FBBD64B6D for ; Tue, 9 May 2017 20:10:19 +0000 (UTC) (envelope-from cara.john@ragtechnology.com) Received: from smtp106.biz.mail.ne1.yahoo.com (smtp106.biz.mail.ne1.yahoo.com [98.138.207.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57C28CE7 for ; Tue, 9 May 2017 20:10:18 +0000 (UTC) (envelope-from cara.john@ragtechnology.com) Received: (qmail 45944 invoked from network); 9 May 2017 20:10:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1494360611; bh=vMbq7g04FpxbRg6dxSSiRU1xz4vDdhrv1hYKeQfUHKs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=RRAzZq3I8DfvCUqEYAiTkSeeQMmuYHCl+T+HxekMetz1Vni/sFvZl++co+fdDu/FjNrlSuyKBc01iHPITMjbjRFk0ml3yI/gAJOLUeG8Y5nR2WoZGEOUqxls1Ov6jwYUFXGmZoftYmlNxsPG2mQg8KHmBt7TuJUhAHubxSGjB9s= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8yX2MG0VM1mfN7nlNSU6dunaJlBPyDi0RmcffUJSbQii0lT 5I2KTIv6aIrvM64sC1tC8aXBXW.x9ymurtV7vmZObdXFMygWZOiD6pIC.ZoE Ws.9MqJjEUU8AKkLQE.sMYRQkT2r1yeU00SgKr7HOY34SRl1z_euHkAsSIJM r8s8yqVROJ9WkxO6EZg0QM63EW2HRuN1KrZ2PkSVLcdeUZCpqUAhSVXjapdp 5cGlpkQDymOxNeIVEIbN94NozYbFhPCBse9F1.ALzRzCydH1ZeHr086Q7qpO .73Pn5e_0qz.SIuUNLwzSeTZ7JtnHCWf5E27X7p11.K9AuNw6BH4fs_av.SO KT4EuzC3W1sAIgL44iwOf3.GfqukIF4EGbyVKlBWkTyhr_.NViNnxDnkqq.k PIDfrj1JD0Zzrf5oAozS5HvOVRszzLxqoA.5i9XEJTstUOD6roDx3pZrDBVv bm5WCZdBmCECNbA1Yj9H9uunuqwsdwwrtvy2G1FAnKgoWG542wc2_jfY7u5q QrozA31XIFERNt0JsQm14k8Pj.e1ukQF1XZrVhnTaBCsQSuRyalLaxfEquhv hIQN9umY6kWgimYUgdZ3AfA4En9M- X-Yahoo-SMTP: gCGfXniswBAVtE1Y5QhOEQgEfZD_GKMn3p92MPnuN8nLTOKabzMm_TrhSj0BTYN.UlRhS5M- From: "Cara John" To: References: In-Reply-To: Subject: RE: Bio-IT World Conference & Expo Attendees List 2017 Date: Tue, 9 May 2017 16:09:51 -0400 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdLE6/BX04APLrK2QGKemX3zbsBppQAJZnYgAAAADuAAAAAEQAAAAA+AAAAAFaAAAAAP0AAAABDQAAAAD8AAAAAO8AAALPKwAAAACvAAAAG6sAAAAkcQAAAACqAAAAAMAAAAABaQAPt45ZA= Content-Language: en-in Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 09 May 2017 20:10:19 -0000 =20 =20 Hi, =20 I hope you=92re doing well. =20 I was wondering if you had a chance to review my previous email that I = sent to you. =20 Kindly let me know your interest so that I can get back to you with = counts and pricing available. =20 Best Regards, Cara =20 From: Cara John [mailto:cara.john@ragtechnology.com]=20 Sent: 04 May 2017 04:09 To: 'freebsd-stable@freebsd.org' Subject: Bio-IT World Conference & Expo Attendees List 2017 Importance: High =20 Hi, =20 Would you be interested in acquiring an Bio-IT World Conference & Expo Attendees Email List 2017? which includes complete contact details and verified email addresses of :-=20 =20 Key decision Makers from Below sector :- =20 =D8 Pharmaceutical =D8 Clinical =D8 Healthcare =D8 IT professionals =D8 Commercial (Biotech + Pharma)=20 =D8 Financial & Services=20 =D8 Academic & Government =D8 Healthcare =D8 Executive & Director =D8 Scientist/Technologist=20 =D8 Sales & Marketing=20 =D8 Manager =D8 Professor =20 If you are interested please let me know your targeted criteria, I can assist you with the count/costs, and more details for your = consideration. =20 Looking forward to hear from you =20 Regards, Cara John Marketing Executive =20 From owner-freebsd-stable@freebsd.org Wed May 10 16:18:00 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5126D67C82 for ; Wed, 10 May 2017 16:18:00 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 6B798EC7 for ; Wed, 10 May 2017 16:17:59 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 76CFA28479 for ; Wed, 10 May 2017 18:12:13 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CF00728439 for ; Wed, 10 May 2017 18:12:12 +0200 (CEST) To: freebsd-stable@freebsd.org From: Miroslav Lachman <000.fbsd@quip.cz> Subject: Missing units in df -h output Message-ID: <59133BDC.8080509@quip.cz> Date: Wed, 10 May 2017 18:12:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 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.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:18:00 -0000 Today I noticed missing units (G) in the output of 'df -h' command if size is exactly 1000G This is on FreeBSD 10.3-RELEASE-p18 amd64 GENERIC /# df -h /vol0/remote_backup/rico Filesystem Size Used Avail Capacity Mounted on tank0/vol0/remote_backup/rico 1.4T 1000 443G 69% /vol0/remote_backup/rico The same without -h # df /vol0/remote_backup/rico Filesystem 1K-blocks Used Avail Capacity Mounted on tank0/vol0/remote_backup/rico 1513215636 1048349068 464866568 69% /vol0/remote_backup/rico I don't know if the G suffix is stripped by formatting to columns / size of field is limited to 4 characters if '-h' is used or anything else. The FS is ZFS if this matters. Is this known issue? Should I file PR for this? Miroslav Lachman From owner-freebsd-stable@freebsd.org Wed May 10 16:36:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C429CD664BF for ; Wed, 10 May 2017 16:36:13 +0000 (UTC) (envelope-from DutchDaemon@FreeBSD.org) Received: from offshore.bengrimm.net (offshore.bengrimm.net [84.22.108.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "offshore.bengrimm.net", Issuer "offshore.bengrimm.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7581D1E9D for ; Wed, 10 May 2017 16:36:12 +0000 (UTC) (envelope-from DutchDaemon@FreeBSD.org) X-H2O-MailScanner-Watermark: 1495038958.67954@5vu06V3o+Vm+3o/BGHa+XA X-Offshore-MailScanner-From: dutchdaemon@freebsd.org X-Offshore-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-1, required 4, autolearn=not spam, ALL_TRUSTED -1.00) X-Offshore-MailScanner: Found to be clean X-Offshore-MailScanner-ID: v4AGZwnB004837 X-Offshore-MailScanner-Information: Please contact the ISP for more information Received: from [10.190.10.116] (D57C4972.static.ziggozakelijk.nl [213.124.73.114]) (authenticated bits=0) by offshore.bengrimm.net (8.15.2/8.15.2) with ESMTPSA id v4AGZwnB004837 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 10 May 2017 18:35:58 +0200 (CEST) (envelope-from DutchDaemon@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.10.3 offshore.bengrimm.net v4AGZwnB004837 X-Authentication-Warning: offshore.bengrimm.net: Host D57C4972.static.ziggozakelijk.nl [213.124.73.114] claimed to be [10.190.10.116] Subject: Re: Missing units in df -h output To: freebsd-stable@freebsd.org References: <59133BDC.8080509@quip.cz> From: DutchDaemon - FreeBSD Forums Administrator Organization: The FreeBSD Forums Message-ID: Date: Wed, 10 May 2017 18:35:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <59133BDC.8080509@quip.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5WF9AqhH8sFMthVx0aAPBQFsI9RaFWdTx" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (offshore.bengrimm.net [84.22.108.242]); Wed, 10 May 2017 18:35:58 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:36:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5WF9AqhH8sFMthVx0aAPBQFsI9RaFWdTx Content-Type: multipart/mixed; boundary="xoD1O8kBq33iF5lE4eOCm8vQxpmm486Jq"; protected-headers="v1" From: DutchDaemon - FreeBSD Forums Administrator To: freebsd-stable@freebsd.org Message-ID: Subject: Re: Missing units in df -h output References: <59133BDC.8080509@quip.cz> In-Reply-To: <59133BDC.8080509@quip.cz> --xoD1O8kBq33iF5lE4eOCm8vQxpmm486Jq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: nl On 10-5-2017 18:12, Miroslav Lachman wrote: > Today I noticed missing units (G) in the output of 'df -h' command if > size is exactly 1000G > > This is on FreeBSD 10.3-RELEASE-p18 amd64 GENERIC > > /# df -h /vol0/remote_backup/rico > Filesystem Size Used Avail Capacity=20 > Mounted on > tank0/vol0/remote_backup/rico 1.4T 1000 443G 69% > /vol0/remote_backup/rico > > The same without -h > > # df /vol0/remote_backup/rico > Filesystem 1K-blocks Used Avail Capacity > Mounted on > tank0/vol0/remote_backup/rico 1513215636 1048349068 464866568 69% > /vol0/remote_backup/rico > > I don't know if the G suffix is stripped by formatting to columns / > size of field is limited to 4 characters if '-h' is used or anything > else. > > The FS is ZFS if this matters. > > Is this known issue? Should I file PR for this? Looks a bit off-by-one-ish. Perhaps 'G' was limited to 999, and 'T' starts at 1000+? Nice catch, if so. --xoD1O8kBq33iF5lE4eOCm8vQxpmm486Jq-- --5WF9AqhH8sFMthVx0aAPBQFsI9RaFWdTx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZE0FpAAoJEA9a9BMWOKcxVYMH/AqQhsYPgL0eH2IK+OIVlYbU u7rtU5luH6db5ld57Nrp/t33Wmdm7EsjxYfqorTIW5rXLgaocG9qJl0NPw1TuOLh laJdNj8H/xLKasNcsyPS21RJQUgAbTN9M2L04YvHaDfC9JwUL/k8C+UNsnTOa97Q FEignRcYa1nvRbumzpJi/YxrAutsR3JFl12gV0puCiHlGL9fwcQLBw1NF3Q2KhPY AYmFlsIJXgzYoimA2y0eMEMZG8yddGaUcyReTqquIvAizz+EOhHvSVuy1qzUR41R cptB/sdUYaoCHgEYnTvizJoynW0WhhUoTsbmKO1m4u08LSRqRilnLFR24bA+tdA= =l1G2 -----END PGP SIGNATURE----- --5WF9AqhH8sFMthVx0aAPBQFsI9RaFWdTx-- From owner-freebsd-stable@freebsd.org Wed May 10 19:24:41 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 829DDD67EAF for ; Wed, 10 May 2017 19:24:41 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 3FF8E1029 for ; Wed, 10 May 2017 19:24:41 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id n4so703613qte.2 for ; Wed, 10 May 2017 12:24:41 -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=Ri9pEvOR2ezwQm98UTdoD2KIlvqEMWxTevIDKX6Glxw=; b=lpQBF9j8lfTKk8avRpqy8/mrSr081X+o9gCWegE3gEVQKqkbGKYUK+sI2Mt1LCxQnh fLYjUA48xRKO1dATdCzcGcGCinWinFdJq+9arKFqcypqpizf+1YrncN0QQ6Ob5qr6qXb 8ao3uwIMfJDCcU1o7RKNKw7OPVFvS4l8/fvYE2CkRT4SQicaSPvKF6wN4pGqraZisams Xh4jlPCJiHG6/JMh0Ss60b4KXCd0yqML91RgAheteuqDymdaqsALFfXcxL0+4NljGl+j HxnxpkvSkslorzjmVWlOmgszNK8KBaQ4u+dDjfC2hjrONZI1pzQvg7wxrO0AAIACw6+7 qGRg== 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=Ri9pEvOR2ezwQm98UTdoD2KIlvqEMWxTevIDKX6Glxw=; b=pCgFZ6/j0KqcrFsBZhLgjsrIvRucFAei/f1ZmA8pLbAX3JxeE6TS4cmGyG2RSFHZBo O3co/XcKBWbmbfvIQjjtnnjKVGG2I74W8QE41/MbGdhrMcOhyNVsmviDoVZetJdrgq43 sFRWIKeRJOK6WE7tU8GzODUftSatvsWe18qeLLXGAA5apOKYpwaXlz9RNE+VvFM/qWC8 W8wDNYtY4UKr6JzI/FkR+UOd/jcIuqE1DojBm97Q7D5puGHLbeC1lp6/W4dpDmN4bkER vc74eRkTJlQefV37hvK+tJ9gXv3OEdd/03BuOVsYuX5olk8CPeztyrC5X3Lb9+v5zIwc EAxg== X-Gm-Message-State: AODbwcBDhKMh+yymzflmdwGN5/rkQ6hX8gd+rl/IrT1wAMYIl8crH3lj 1Tm5pO4o/caiXLtU5dDbpMhjMryGwH/zpxM= X-Received: by 10.237.36.154 with SMTP id t26mr138550qtc.180.1494444280236; Wed, 10 May 2017 12:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.55.183 with HTTP; Wed, 10 May 2017 12:24:39 -0700 (PDT) From: Robert Simmons Date: Wed, 10 May 2017 15:24:39 -0400 Message-ID: Subject: FreeBSD Vagrant Box Kernel Panic To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:24:41 -0000 I was reading the previous thread about the current Vagrant box for FreeBSD 11.0-STABLE on atlas.hashicorp.com. The broken box is still not updated. Who is the maintainer of these boxes? On a side note, the reason freebsd/FreeBSD-11.0-RELEASE is revoked is there is a newer -p1 box: https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-RELEASE-p1 It appears that the maintainer of the boxes should create a 11.0-RELEASE-p10 box and revoke the -p1 box. From owner-freebsd-stable@freebsd.org Wed May 10 22:34:04 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8CC7D66AAA for ; Wed, 10 May 2017 22:34:04 +0000 (UTC) (envelope-from ocinquin@uci.edu) Received: from mda3.es.uci.edu (mda3.es.uci.edu [128.200.80.6]) (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 92527111C for ; Wed, 10 May 2017 22:34:04 +0000 (UTC) (envelope-from ocinquin@uci.edu) Received: from ismtp2.es.uci.edu (ismtp2.es.uci.edu [128.195.153.32]) by mda3.es.uci.edu (8.14.4/8.14.4) with ESMTP id v4AMTlQC514350 for ; Wed, 10 May 2017 15:29:47 -0700 Received: from vcv065163.vpn.uci.edu (vcv065163.vpn.uci.edu [128.195.65.163]) (authenticated bits=0) by ismtp2.es.uci.edu (8.14.4/8.14.4) with ESMTP id v4AMTeT5025173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 May 2017 15:29:41 -0700 X-UCInetID: ocinquin From: Olivier Cinquin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Kernel panic in smp rendezvous Message-Id: Date: Wed, 10 May 2017 15:29:39 -0700 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 22:34:04 -0000 Hi, I'm getting the following kernel panics on recent 11-STABLE (r317883): spin lock 0xffffffff81df43d0 (smp rendezvous) held by 0xfffff8019c7a7000 = (tid 100845) too long timeout stopping cpus panic: spin lock held too long cpuid =3D 12 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe3e64caf2a0 vpanic() at vpanic+0x186/frame 0xfffffe3e64caf320 panic() at panic+0x43/frame 0xfffffe3e64caf380 _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x311/frame = 0xfffffe3e64caf3f0 smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x101/frame = 0xfffffe3e64caf470 smp_masked_invlpg_range() at smp_masked_invlpg_range+0x50/frame = 0xfffffe3e64caf4a0 pmap_invalidate_range() at pmap_invalidate_range+0x196/frame = 0xfffffe3e64caf4e0 vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2f/frame = 0xfffffe3e64caf530 thread_free() at thread_free+0x39/frame 0xfffffe3e64caf550 thread_reap() at thread_reap+0x10e/frame 0xfffffe3e64caf570 proc_reap() at proc_reap+0x6bd/frame 0xfffffe3e64caf5b0 proc_to_reap() at proc_to_reap+0x48c/frame 0xfffffe3e64caf600 kern_wait6() at kern_wait6+0x49e/frame 0xfffffe3e64caf6b0 sys_wait4() at sys_wait4+0x78/frame 0xfffffe3e64caf8a0 amd64_syscall() at amd64_syscall+0x6c4/frame 0xfffffe3e64cafa30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe3e64cafa30 The panics occur sporadically and seemingly randomly. They occur on multiple machines with the same configuration, and on older revisions of 11-STABLE as well as r317883 (I cannot easily bisect this down to a specific commit given that it can take days or sometimes weeks for the panic to occur). Note that my kernel is compiled with "options IPSEC", = but that does not seem to be relevant. My understanding of the overall problem is that an IPI is sent to all = cores by smp_rendezvous_cpus, but that some of the cores do not respond to it = (or at least do not respond to it correctly and in time). More specifically, = I can find 61 threads that seem to be blocked in cpustop_handler on an = atomic operation to indicate that they have stopped in response to the IPI. = This operation is CPU_SET_ATOMIC(cpu, &stopped_cpus); CPU_SET_ATOMIC boils = down to a call to "atomic_set_long" (not sure where that is itself defined = for amd64). Either there is a line numbering problem, or this suggests that perhaps there is a deadlock at this step (unless there's some sort of livelock and CPU_SET_ATOMIC is the place where the threads spend most of their time). Looking at the thread backtraces as a whole, I can see the one that triggered the panic, the 61 that are in cpustop_handler, and a lot of sleeping threads. I guess each core should have an active thread, and = this is an architecture with 64 cores, so that leaves 64 - (1 + 61) =3D 2 = cores that are unaccounted for. Interestingly, for 2 different panics for = which I have a vmcore file these numbers are the same. For these two panics, the IDs of the cores that are neither in cpustop_handler nor calling the smp rendez vous are not the same (#18 and #19 in one instance, #44 and #45 = in the other instance) but in both instances the IDs are consecutive; = perhaps that's relevant. I've uploaded a full set of backtraces at https://gist.github.com/cinquin/d63cdf9de01b0b8033c47128868f2d38 and a dmesg at = https://gist.github.com/cinquin/17c0cf6ac7832fd1b683488d08d3e69b (in short, the machine is a 4 processor Opteron 6274 system). I'm = pasting below an example backtrace of the threads in stopcpu_handler. Any suggestions as to what the problem might be and how to solve it? = I've saved the core and can provide further information. Thanks Olivier Cinquin A total of 61 threads are along the lines of #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275 #1 0xffffffff8105a6f5 in ipi_nmi_handler () at = /usr/src/sys/x86/x86/mp_x86.c:1231 #2 0xffffffff80ef740a in trap (frame=3D0xfffffe3e687f7f30) at = /usr/src/sys/amd64/amd64/trap.c:185 #3 0xffffffff80edbd03 in nmi_calltrap () at = /usr/src/sys/amd64/amd64/exception.S:510 ... (kgdb) frame 0 #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275 1275 CPU_SET_ATOMIC(cpu, &stopped_cpus); (kgdb) list 1270 cpu =3D PCPU_GET(cpuid); 1271=09 1272 savectx(&stoppcbs[cpu]); 1273=09 1274 /* Indicate that we are stopped */ 1275 CPU_SET_ATOMIC(cpu, &stopped_cpus); 1276=09 1277 /* Wait for restart */ 1278 while (!CPU_ISSET(cpu, &started_cpus)) 1279 ia32_pause(); (kgdb) p stopped_cpus $1 =3D {__bits =3D 0xffffffff81df4368} (kgdb) p started_cpus $2 =3D {__bits =3D 0xffffffff81df4418} From owner-freebsd-stable@freebsd.org Thu May 11 07:51:48 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A9CDD6365C for ; Thu, 11 May 2017 07:51:48 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (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 91D704E for ; Thu, 11 May 2017 07:51:46 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id v4B7SjET094408; Thu, 11 May 2017 09:28:45 +0200 (CEST) Received: from [217.29.44.134] ([217.29.44.134]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id v4B7SjRg059251; Thu, 11 May 2017 09:28:45 +0200 (CEST) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Message-Id: <1E518258-C7BF-4CF9-9D78-39B94AF29CC3@punkt.de> Content-Type: multipart/signed; boundary="Apple-Mail=_F82C0703-82EE-4EF9-BBF9-08918BBBDE80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FreeBSD Vagrant Box Kernel Panic Date: Thu, 11 May 2017 09:28:44 +0200 In-Reply-To: Cc: freebsd-stable@freebsd.org To: Robert Simmons References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 07:51:48 -0000 --Apple-Mail=_F82C0703-82EE-4EF9-BBF9-08918BBBDE80 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hello, > Am 10.05.2017 um 21:24 schrieb Robert Simmons : > It appears that the maintainer of the boxes should create a > 11.0-RELEASE-p10 box and revoke the -p1 box. The official Hashicorp boxes have been invoking freebsd-update on startup for a while, now. So every box automatically updates itself to the latest patchlevel. We have started to roll our own boxes, so I'm not perfectly up-to-date. Patrick --Apple-Mail=_F82C0703-82EE-4EF9-BBF9-08918BBBDE80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZFBKtAAoJEJBvLuLt2olcAvAH/0Bm5D5dsxkW9Xy+rjNuZCZR GdqkDfZtiKeI9NVVdiFXNYAdTBIsiTedMVHYfejRtXcGnE9PU+ahqs0ARfM2iX9X 4HjF6M6x+qeSzfi6iCuWJwEFqk78EGiKuVeFR3hYYx2Ge4+uJ7jdb+o6KDgAe/LY 1fy5JzpuT75XeLu73Jqi8rntIoXLCp/MfQU5/eNUOvCq9O0ZgQxI95UH+xGUnGVz HKHc79AB4t4K+VinaNXP74ogTXJK24sA/9jLBUDCaKMOgP7Zm/eu6AqykNYP7k4B hlftVb2mRpVuUb/rLetN+0a8OOE5EgJb0UEpZPWZqZ/2dgZWtTmmu5Z92aRJplk= =/0lp -----END PGP SIGNATURE----- --Apple-Mail=_F82C0703-82EE-4EF9-BBF9-08918BBBDE80-- From owner-freebsd-stable@freebsd.org Thu May 11 10:01:33 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D05DDD6696D for ; Thu, 11 May 2017 10:01:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 5FA95DB2 for ; Thu, 11 May 2017 10:01:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4BA1Qtr005215 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 May 2017 13:01:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4BA1Qtr005215 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4BA1PxH005214; Thu, 11 May 2017 13:01:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 May 2017 13:01:25 +0300 From: Konstantin Belousov To: Olivier Cinquin Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic in smp rendezvous Message-ID: <20170511100125.GW1622@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 10:01:33 -0000 On Wed, May 10, 2017 at 03:29:39PM -0700, Olivier Cinquin wrote: > Hi, > I'm getting the following kernel panics on recent 11-STABLE (r317883): > > spin lock 0xffffffff81df43d0 (smp rendezvous) held by 0xfffff8019c7a7000 (tid 100845) too long > timeout stopping cpus > panic: spin lock held too long > cpuid = 12 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe3e64caf2a0 > vpanic() at vpanic+0x186/frame 0xfffffe3e64caf320 > panic() at panic+0x43/frame 0xfffffe3e64caf380 > _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x311/frame 0xfffffe3e64caf3f0 > smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x101/frame 0xfffffe3e64caf470 > smp_masked_invlpg_range() at smp_masked_invlpg_range+0x50/frame 0xfffffe3e64caf4a0 > pmap_invalidate_range() at pmap_invalidate_range+0x196/frame 0xfffffe3e64caf4e0 > vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2f/frame 0xfffffe3e64caf530 > thread_free() at thread_free+0x39/frame 0xfffffe3e64caf550 > thread_reap() at thread_reap+0x10e/frame 0xfffffe3e64caf570 > proc_reap() at proc_reap+0x6bd/frame 0xfffffe3e64caf5b0 > proc_to_reap() at proc_to_reap+0x48c/frame 0xfffffe3e64caf600 > kern_wait6() at kern_wait6+0x49e/frame 0xfffffe3e64caf6b0 > sys_wait4() at sys_wait4+0x78/frame 0xfffffe3e64caf8a0 > amd64_syscall() at amd64_syscall+0x6c4/frame 0xfffffe3e64cafa30 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe3e64cafa30 > > > The panics occur sporadically and seemingly randomly. They occur on > multiple machines with the same configuration, and on older revisions of > 11-STABLE as well as r317883 (I cannot easily bisect this down to a > specific commit given that it can take days or sometimes weeks for the > panic to occur). Note that my kernel is compiled with "options IPSEC", but > that does not seem to be relevant. > > My understanding of the overall problem is that an IPI is sent to all cores > by smp_rendezvous_cpus, but that some of the cores do not respond to it (or > at least do not respond to it correctly and in time). More specifically, I > can find 61 threads that seem to be blocked in cpustop_handler on an atomic > operation to indicate that they have stopped in response to the IPI. This > operation is CPU_SET_ATOMIC(cpu, &stopped_cpus); CPU_SET_ATOMIC boils down > to a call to "atomic_set_long" (not sure where that is itself defined for > amd64). Either there is a line numbering problem, or this suggests that > perhaps there is a deadlock at this step (unless there's some sort of > livelock and CPU_SET_ATOMIC is the place where the threads spend most of > their time). > > Looking at the thread backtraces as a whole, I can see the one that > triggered the panic, the 61 that are in cpustop_handler, and a lot of > sleeping threads. I guess each core should have an active thread, and this > is an architecture with 64 cores, so that leaves 64 - (1 + 61) = 2 cores > that are unaccounted for. Interestingly, for 2 different panics for which I > have a vmcore file these numbers are the same. For these two panics, the > IDs of the cores that are neither in cpustop_handler nor calling the smp > rendez vous are not the same (#18 and #19 in one instance, #44 and #45 in > the other instance) but in both instances the IDs are consecutive; perhaps > that's relevant. > > I've uploaded a full set of backtraces at > https://gist.github.com/cinquin/d63cdf9de01b0b8033c47128868f2d38 and a > dmesg at https://gist.github.com/cinquin/17c0cf6ac7832fd1b683488d08d3e69b > (in short, the machine is a 4 processor Opteron 6274 system). I'm pasting below > an example backtrace of the threads in stopcpu_handler. > > Any suggestions as to what the problem might be and how to solve it? I've > saved the core and can provide further information. > > Thanks > Olivier Cinquin > > A total of 61 threads are along the lines of > > #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275 > #1 0xffffffff8105a6f5 in ipi_nmi_handler () at /usr/src/sys/x86/x86/mp_x86.c:1231 > #2 0xffffffff80ef740a in trap (frame=0xfffffe3e687f7f30) at /usr/src/sys/amd64/amd64/trap.c:185 > #3 0xffffffff80edbd03 in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:510 > ... > (kgdb) frame 0 > #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275 > 1275 CPU_SET_ATOMIC(cpu, &stopped_cpus); > (kgdb) list > 1270 cpu = PCPU_GET(cpuid); > 1271 > 1272 savectx(&stoppcbs[cpu]); > 1273 > 1274 /* Indicate that we are stopped */ > 1275 CPU_SET_ATOMIC(cpu, &stopped_cpus); > 1276 > 1277 /* Wait for restart */ > 1278 while (!CPU_ISSET(cpu, &started_cpus)) > 1279 ia32_pause(); > (kgdb) p stopped_cpus > $1 = {__bits = 0xffffffff81df4368} > (kgdb) p started_cpus > $2 = {__bits = 0xffffffff81df4418} > It would be interesting to see only the backtraces for threads which are on CPUs, i.e. all nmi_stop_handler()-threads and others. >From your description, it looks like that there are two problems, both of which might have the same cause. Initial thread broadcasts tlb shootdown IPI, calling smp_targeted_tlb_shootdown(). The function locks the smp_ipi_mtx spinlock. After IPI is sent, the function loops waiting for other cores acknowledging the IPI. The is the while (*p_cpudone != generation) ia32_pause(); loop which reads from other CPU PCPU area. Then, other thread decides that it should execute shootdown as well, and tries to lock the same smp_ipi_mtx spinlock. It times out due to the initial thread, and panics. Panic(9) sends broadcast NMI to all cores except self to stop the machine. This is what you see in the backtrace for all except one thread. If you do not see NMI handler entrance for the initial thread, then this indicates the second problem, any way showing just backtraces for each CPU would clear the possible confusion. The question of why shootdown times out is open anyway. You should examine pc_smp_tlb_done in each PCPU area to see whether CPUs properly reacted to the IPI and it is initiator which does not see the update, or it is some CPU which did not received IPI. This might be a CPU errata. I remember much earlier AMD CPUs having an issue with tight read loop, could be that it is it. Did you tried to update BIOS ? Also install sysutils/devcpu-data and upgrade microcode on the processor online. I skimmed over the AMD document 48063 Rev. 3.24 "Revision Guide for AMD Family 15h Models 00h-0Fh Processors", nothing oustanding came out except possibly Errata 619: 619 Non-Posted Reads May Block Write Dependent on Probe Responses The northbridge may stall indefinitely on non-posted reads when a posted write becomes dependent on probe responses. You might also try to change the loop I cited above to some variant like while (*p_cpudone != generation) { ia32_pause(); mfence(); } and report whether any of the magic helped. From owner-freebsd-stable@freebsd.org Sat May 13 10:53:23 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7F99D69CFB for ; Sat, 13 May 2017 10:53:23 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470C41ED9 for ; Sat, 13 May 2017 10:53:22 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mandree.no-ip.org ([77.181.128.133]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LmKOI-1di0OS3cX4-00Zv4W; Sat, 13 May 2017 12:47:59 +0200 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id D00DB23CF5A; Sat, 13 May 2017 12:47:46 +0200 (CEST) Subject: Re: Formatting a 4k disk on FreeBSD with ext2 To: HSR Hackspace Cc: freebsd-stable@freebsd.org, Theodore Ts'o References: From: Matthias Andree Message-ID: Date: Sat, 13 May 2017 12:47:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:3QWUiqeiMKdiHuDLOgEOD1sQXIBiDhNrycN1rqu9WV+okzL6hop RuPAoKaGq9DQrK/fipAT9a2I/kHGyqo0bgFYUi9vfaBtw86M9hkWiwMBvw1VjUbkvIS5ENj lLegGcVbggI4kyXJHBsZ4Cy4kf83rH+gmu1VXHwotgg1BpSHEjab//agIzVUryW6OL3uk5B fS6iF9YX6GA9/Qo3uLmcg== X-UI-Out-Filterresults: notjunk:1;V01:K0:JFULLNuDscI=:FqLzUrkmll34gJxvAcNsWY fLyj4svMK3lBZ7G3//JIiZbub58hwaOKd1X3UGk+LwlKoMMjbfJHd8t/He6HspRa1QZVBe4rM RbFih+zCmz7KbZkmoYRAHjM4D/dkNzNpSk4zP7Cc2OHccOOyqwPghT8CBATXEvVRYh2bB9fta t4/2F5uDxnMfMm9QPVREt9eQCaCcfEVYrkWjlJ5gO161k7Cm0qIcaJPgeYQSlVscrkF8c7D4L 7kmdO22G/cEsgHmO/i10zvPyBl6RhgxWYih6G3xyZPQUBU1FjByzPAhM+yHf0zBKmR1HDJlHo 3qd+oeTVV0xTEPdoXoYn5gk3lc/NGFvdvl64o6FcNjPgeTLQ/bemji35slONM7V9i0WlCigF8 KBpsDTDrhRK3scobUO0ZI1E3ZIYd+0FaT1mbI09NYh3Kw0il5RBdHuropiRkY2FOv3lcE6OcM +mbqa85MHDiv4e2B6kqPuxN8PPAxamorlNVP2He7Odop8ZAAbFB8rvsz5jsa9SJJfFd3T5I5W jUjfjiN96KjzszX4SUlXVBS7qwlVkVmXUTxZSYkh/JIAuud3KLFLZJZpcD4Q5lEpvmvyifJqO WmQOomv6jRv4p27RG6Vup6pGyk2sO+IZuyvZx9+1H70QpqpfFy6A7vwRv36ErBdSPu5Z5dBGM RVmyJynHEtn1HUOvUkLeGCYUWJ/ae0QMFMVm/aLNTnuLLUs+jx/ewS9H0NlXGB9ZJZvrA46c5 I14CioGf6vOyFtDBRcKWv3PuXW3CmRUrnw8RbHlUD+420YauOfzIkp4w9eUZvCQCd9MIMge8b 6aU4Sn9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 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, 13 May 2017 10:53:24 -0000 Am 08.05.2017 um 17:42 schrieb HSR Hackspace: > Hi folks; > > I'm trying to format a 300 GB partition on x86_64 box running running > BSD 10.1 with HW RAID configuration. All my attempt so far have > failed. Below are the logs for same. > > Logs: > > 1. pod1208-wsa07:rtestuser 106] ./mkfs.ext3 /dev/da0p7 > mke2fs 1.43.4 (31-Jan-2017) > Warning: could not erase sector 2: Invalid argument---------> Please show the output of $ env LANG=3D LANGUAGE=3D LC_ALL=3DC mkfs.ext3 -V It should print 1.43.4 for the program _and the library_ (the latter isn't shown above). Then, please run mkfs.ext3 under truss, or under ktrace, and upload the truss or kdump log somewhere and post the URL. Do not mail the log, it's gonna be too big. "Invalid argument" aka EINVAL looks like misaligned access. Now, diskinfo provided the right sectorsize (4096), which it - as of FreeBSD 10.3 - obtains with ioctl(fd, DIOCGSECTORSIZE, §orsize), where sectorsize is a u_int, and unsigned int. Which RAID device is it, what's its structure?