[Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?

[Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?

[Brian Foster]

Hello,

 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 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).

 Any pointers would be appreciated.

cheers!
	-blf-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated               |  http://www.maximintegrated.com/

Re: [Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?

[Brian Norris]

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

Re: [Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?

[Brian Foster]

On Tuesday 25-February-2014 23:21:41 Brian Norris wrote:
> 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...

Hi Brian.

 No, yer are not missing it.  I made a mistake,
 and accidently copy-and-pasted the text from
 BusyBox's built-in version of ‘ubiattach',
 not the mtd-tools version.  Not that it makes
 any difference, the behaviour is identical.

 I sent a correction to the list but it is stuck
 in moderation.

> >  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.

 Exactly, this is why I am so puzzled.

> >  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?

 Maybe, but seems unlikely:  It's the same compiler.
 Also, one of our FAEs has just reported what looks
 like the same behaviour on v2.6.36, also suggesting
 the compiler is unlikely to be a fault here.
 Interesting possibility, however!  Thanks.

 Another guess: We are using a static /dev/ubi_ctrl
 node.  However, that is a dynamic minor misc device,
 so I am currently _guessing_ the v3.10 system assigned
 a different minor number than the v2.6.36 system usually
 does (and the FAE's system also picked a different minor
 for some currently unknown reason).   I will check this
 possibility as soon as I can ....

cheers!
	-blf-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated               |  http://www.maximintegrated.com/

Re: SOLVED: [Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?

[Brian Norris]

+Artem

Replying just to get the message through to the mailing list

On Wed, Feb 26, 2014 at 10:54:02AM +0100, Brian Foster wrote:
> On Tuesday 25-February-2014 23:42:11 Brian Foster wrote:
> > On Tuesday 25-February-2014 23:21:41 Brian Norris wrote:
> > >[...]
> > 
> >  Another guess: We are using a static /dev/ubi_ctrl
> >  node.  However, that is a dynamic minor misc device,
> >  so I am currently _guessing_ the v3.10 system assigned
> >  a different minor number than the v2.6.36 system usually
> >  does (and the FAE's system also picked a different minor
> >  for some currently unknown reason).   I will check this
> >  possibility as soon as I can ....
> 
>  Yep, that's the problem.  The “failing” systems have allocated
>  a different minor device number (according to /proc/misc) than
>  that of the static /dev/ubi_ctrl node.
> 
> cheers!
> 	-blf-
> 
> p.s.  I am not sure if this will go to the list or into
>      moderation, as my previous attempt to reply to myself
>      went into moderation ....   ;-\    (Brian Norris,
>      please feel free to re-send this to the list if it
>      doesn't make it, or kick the moderator  ;-)  or ....)

The moderator is thinking of turning some of the problematic filtering
off. You are not the only one who has ever been stopped by this.

> -- 
> Brian Foster
> Principal MTS, Software        |  La Ciotat, France
> Office:  +33 (0)4 42 98 15 35  |  Fax:  +33 (0)4 42 08 33 19
> Maxim Integrated               |  http://www.maximintegrated.com/
> 

Brian