From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 30 22:53:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CF9D1A5 for ; Tue, 30 Sep 2014 22:53:41 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0074.outbound.protection.outlook.com [157.56.111.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C8E9FAA for ; Tue, 30 Sep 2014 22:53:39 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0943.namprd08.prod.outlook.com (25.160.131.26) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 22:53:59 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 22:53:40 +0000 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: dumpsys/savecore on AF-4Kn drives? Thread-Topic: dumpsys/savecore on AF-4Kn drives? Thread-Index: AQHP3QFgvwLpNOmcHUaIK0Ete9ljBw== Date: Tue, 30 Sep 2014 22:53:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.80.217.3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0943; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(199003)(189002)(2351001)(229853001)(107886001)(110136001)(54356999)(107046002)(4396001)(120916001)(76482002)(97736003)(99286002)(101416001)(87936001)(105586002)(64706001)(106116001)(2656002)(77096002)(31966008)(83506001)(66066001)(80022003)(106356001)(85306004)(95666004)(20776003)(21056001)(50986999)(85852003)(99396003)(92566001)(10300001)(36756003)(46102003)(86362001)(92726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0943; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <1C6A75B497BE8A49B67831132974C60C@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 22:53:41 -0000 Hi folks, Does anyone out there have AF-4Kn drives (both logical and physical sector size is 4KB)? Have you been able to drop a core to one, and successfully save the core on the way back up? I'm working on adding AF-4Kn support to an older version of FreeBSD (based on 7 - yeah, I know... :-P), using -CURRENT as a reference. Things look good at the GEOM level and higher; the GEOM utils report correct sizes, UFS runs fine, etc. If I manually break into the debugger and 'call doadump', it appears to work; at least, it does not report any errors. But when I reboot, `savecore' complains: error reading dump header at offset 0 in /dev/mirror/gm1: Invalid argument (Yes, it's dumping to a mirror; no, that's not the problem: the mirror is configured using the 'prefer' balancing algorithm, as described in gmirror(8), and we've been doing this without issue for years.) I'm trying to figure out if the problem is on the dumpsys side, the savecore side, or if they're both broken for AF-4Kn. In particular, 'struct kerneldumpheader' is 512 bytes, and it looks like most calls to dump_write() in the full-dump context (not minidumps) pass either the size of the structure, or an explicit 512, for the 'length' argument. That's the case in both the 7-ish version I'm porting to, and in -CURRENT. There's no AF-4Kn-aware bootstrap in the version we're using (emaste@ - does the new UEFI bootstrap in 10-STABLE work w/ AF-4Kn drives?), so one of the drives is 512n, and I could probably find some space on there to save the core to. But that device is small, and we have other uses for it, so I'd like to avoid reserving a large chunk of it. Any thoughts? Thanks, Ravi