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

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

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-

+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