ioctl call fails with unknown command
mch...@gmail.com
message: unknown command fd(3). it seems that the ioctl
call is not invoking my driver ioctal method because the debug message
inside my ioctl method never get printed out.
although this may seems like i am using incorrect file descriptor,
since my ioctl method is not even being called, i know i am
using the correct file descriptor because my 'read' method gets
invoked fine.
And using the same code and driver, i was able to get it to work on a
486 target machine but it doesn't seem to work with this
particular linux version.
how can i debug this code? where in the kernel code can i begin to
trace to see what is happening? which file/function gets
called when ioctl function is fisrt called?
(i don't have a debugger and i am not able to gdb the code so i need
to resort to printing out debug messages in the source
code.)
thank you in advance.
ioctl call fails with unknown comma
Janaka
I am assuming that you are using 2.6.x kernel. If so use one of the
macros provided by the kernel to specify IOCTLs such as:
_IO( 'k', 0)
_IOR( 'k', 2)
_IOW( 'k', 4)
_IOWR( 'k', 5)
etc.
Make sure the file open succeeds before attempting to call its IOCTLs.
Eg:
myfile = open("/dev/mydevice0", O_RDWR | O_SYNC);
ioctl( myfile, 4, 1234);
mch...@gmail.com
i can even invoke my read/write method.
i have registered my command using magic number
0x81 and also tried magic number 0x82, etc..
so far still havent' been able to do ioctl call in the driver.
the vendor says there's no problem with the kernel.
do you have any more suggestions?
thank you in advance.
On Feb 19, 10:10 pm, Janaka <jana...@optiscan.com> wrote:
> On Feb 20, 1:18 pm, mcha...@gmail.com wrote:
>
>
>
>
>
> > hi, when trying to doioctlcallto my driver, i keep getting an error
> > message:unknowncommandfd(3). it seems that theioctl
>
> >callis not invoking my driver ioctal method because the debug message
> > inside myioctlmethod never get printed out.
> > although this may seems like i am using incorrect file descriptor,
> > since myioctlmethod is not even being called, i know i am
>
> > using the correct file descriptor because my 'read' method gets
> > invoked fine.
> > And using the same code and driver, i was able to get it to work on a
> > 486 target machine but it doesn't seem to work with this
>
> > particular linux version.
>
> > how can i debug this code? where in the kernel code can i begin to
> > trace to see what is happening? which file/function gets
>
> > called whenioctlfunction is fisrt called?
> > (i don't have a debugger and i am not able to gdb the code so i need
> > to resort to printing out debug messages in the source
>
> > code.)
>
> > thank you in advance.
> >ioctlcallfailswithunknowncomma
>
> I am assuming that you are using 2.6.x kernel. If so use one of the
> macros provided by the kernel to specify IOCTLs such as:
> _IO( 'k', 0)
> _IOR( 'k', 2)
> _IOW( 'k', 4)
> _IOWR( 'k', 5)
>
> etc.
>
> Make sure the file open succeeds before attempting tocallits IOCTLs.
> Eg:
> myfile = open("/dev/mydevice0", O_RDWR | O_SYNC);
>
> ioctl( myfile, 4, 1234);- Hide quoted text -
>
> - Show quoted text -
Bill Waddington
Show us the code.
What does your ioctl() entry point (or points) look like? How are you calling
it? What does you file_operations structure look like?
Bill
--
William D Waddington
william.w...@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
Janaka
Normally on most IOCTL interfaces there are about 4-6 checks before
the actual command hits the "switch" statement. These checks makes
sure:
- That the commands match the magic number and are less than the
defined max commands
- Direction and size of arguments
If any of these tests fails it does not hit the actual switch
statement. Put a printk at the top of your device driver IOCTL
function before any of those checks are carried out and see whether it
hits that. And as Bill says it will help if you can post some of the
relavent code blocks.
Bill Waddington
To cut to the chase, is the failing case running a 64 bit kernel? If
so it's probably/maybe that you havent't implemented compatible ioctls
and/or unlocked ioctls:
http://lwn.net/Articles/119652/
For a few kernel versions, there was an even nastier way of telling
the kernel that ioctls were 64 bit compatible, IIRC.
Just a WAG,
Bill Waddington
<william.w...@beezmo.com> wrote:
[continuing this tacky habit of replying to myself...]
I should have added that this issue only comes up if running a 64 bit
kernel and a 32 bit calling application - I think.