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

[Brian Foster <brian.foster@maximintegrated.com>]

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/