`ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?
Subsystems (2)
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-
Signature · 3 lines
Brian Foster Principal MTS, Software | La Ciotat, France Maxim Integrated | http://www.maximintegrated.com/
Hi Brian,
Quoted 6 lines · Brian Foster
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).
Quoted 7 lines
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...
Quoted 3 lines
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.
Quoted 1 line
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
include/uapi/mtd/ubi-user.h +1 -1
@@ -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
Quoted 13 lines · On Tuesday 25-February-2014 23:21:41 Brian Norris wrote:
Hi Brian,
Quoted 10 lines · Brian Foster
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:
Quoted 7 lines
Quoted 3 lines
# 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.cin 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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 1 line
Any pointers would be appreciated.
Well, here's a wild guess; it looks like struct
ubi_attach_reqis 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-
Signature · 3 lines
Brian Foster Principal MTS, Software | La Ciotat, France Maxim Integrated | http://www.maximintegrated.com/
A message that is not in the archive (sent off-list or not yet received): 3384625.n7jGnVRFVi@laclwks004
Re: SOLVED: [Q] `ubiattach: ioctl 0x40186f40 failed: Inappropriate ioctl for device' - What changed?
+Artem
Replying just to get the message through to the mailing list
Quoted 16 lines · Brian Foster
Quoted 10 lines · On Tuesday 25-February-2014 23:42:11 Brian Foster wrote:
Quoted 1 line · On Tuesday 25-February-2014 23:21:41 Brian Norris wrote:
[...]
Another guess: We are using a static
/dev/ubi_ctrlnode. 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_ctrlnode.
Quoted 8 lines
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.
Quoted 6 lines
Signature · 4 lines
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