From patchwork Wed Feb 26 07:21:41 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 324215 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id DE35C2C00A2 for ; Wed, 26 Feb 2014 18:23:17 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WIYpV-0000Qc-K8; Wed, 26 Feb 2014 07:22:57 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WIYpU-0003cM-0i; Wed, 26 Feb 2014 07:22:56 +0000 Received: from mail-ig0-x231.google.com ([2607:f8b0:4001:c05::231]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WIYpR-0003bv-Kf for linux-mtd@lists.infradead.org; Wed, 26 Feb 2014 07:22:54 +0000 Received: by mail-ig0-f177.google.com with SMTP id h3so792779igd.4 for ; Tue, 25 Feb 2014 23:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=qEF9KtDEmFkiOwtw8ukKTU03qWJ4NfDpE6shUtAwZLs=; b=BcvK+UICCA10lR0rNoFc7VHzb7CIJmt3IZKuxzbCfJSSq6Ex/VnNsZqc0pjjh5OQSX 8KqmZY54uv++2+0JaE4lyk9HvRleNa7TbgjnqevP5BaQngA8f79Pwn4tOXpbe16rJvOL tyPlGTWaKD/z79UFw4KwLucivZ3bh+Lf0S+BEZxxZuze8/vDcEbjFX0IwO7YCQ7t8KhR mdeHMva/NnmvmN1hmC9yyL9Qe56UYdpKWS2ONzghbydzxEFTk753cMLZt+KmEsUevKmd dwh04h3ph7L33NsksnZd+8jDkX/B/Mgm9U2om5BSJLk9e4AXBlNbk24c/WHQL4eroQt4 ndqw== X-Received: by 10.50.120.68 with SMTP id la4mr1461005igb.24.1393399352156; Tue, 25 Feb 2014 23:22:32 -0800 (PST) Received: from norris-Latitude-E6410 (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by mx.google.com with ESMTPSA id u1sm3406843igm.8.2014.02.25.23.22.30 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 25 Feb 2014 23:22:31 -0800 (PST) Date: Tue, 25 Feb 2014 23:21:41 -0800 From: Brian Norris To: Brian Foster Subject: Re: [Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed? Message-ID: <20140226072141.GA13420@norris-Latitude-E6410> References: <4790760.yeQTJBGPZK@laclwks004> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4790760.yeQTJBGPZK@laclwks004> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140226_022253_756834_5356A915 X-CRM114-Status: GOOD ( 16.95 ) X-Spam-Score: -2.0 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (computersforpeace[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: "linux-mtd@lists.infradead.org" X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Hi Brian, On Tue, Feb 25, 2014 at 05:01:18PM +0100, Brian Foster wrote: > Using an (admittedly ancient) BuildRoot v2010.11 > (which uses v2.6.36.4 kernel headers) with an > (also admittedly ancient) v2.6.36.4 Linux kernel, > ubiattach(1) works fine. The ‘ubiattach’ is of > vintage v1.4.6 (and has not been modified). > > However, using that _identical_ ‘ubiattach’ binary > (which is for an ARM926EJ-S CPU) with a more recent > v3.10.30 kernel, it fails. For example: > > # ubiattach -m7 -d0 /dev/ubi_ctrl > ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device > # I'm honestly not sure where the above print came from. I'm checking out ubiattach.c in mtd-utils v1.4.6, and I don't see this print. But perhaps I'm just missing it... > I assume the value of, and/or parameter to, some > ioctl command has changed v2.6.36 → v3.10, but > am at a loss as to just _what_ changed (or why). The parameter *shouldn't* have changed. We try to keep ABI compatibility, as Linus sometimes loudly proclaims. And I don't think I've seen any changes to ioctl(UBI_IOCATT). In fact, the reported ioctl number (0x40186f40) still matches my functioning mtd-utils + 3.8.x kernel. > Any pointers would be appreciated. Well, here's a wild guess; it looks like struct ubi_attach_req is the only UBI ioctl struct that does not have the __attribute__((packed)) annotation. So it's possible that your compiler didn't pack the struct the same for your 3.10 kernel. Perhaps the following patch would help? Brian diff --git a/include/uapi/mtd/ubi-user.h b/include/uapi/mtd/ubi-user.h index 723c324590c1..9dd7f31a2527 100644 --- a/include/uapi/mtd/ubi-user.h +++ b/include/uapi/mtd/ubi-user.h @@ -268,7 +268,7 @@ struct ubi_attach_req { __s32 vid_hdr_offset; __s16 max_beb_per1024; __s8 padding[10]; -}; +} __packed; /** * struct ubi_mkvol_req - volume description data structure used in