* ioctl constants
@ 2000-03-28 20:25 Chris Hallinan
0 siblings, 0 replies; 2+ messages in thread
From: Chris Hallinan @ 2000-03-28 20:25 UTC (permalink / raw)
To: linuxppc-embedded
I'm using kernel 2.2.13 and a slightly modified version of serial.c to
operate an additional 16550 device at a non-standard i/o address.
I'm troublshooting a ppp disconnect problem which has led me to the
serial driver. I've noticed that a large number of rs_ioctl() calls hit
the driver with incorrect constants. Using printk()'s, I'm able to
determine what values are being passed in, but of course, not who is
calling them.
I've studied the related header files: the constants used in serial.c
are hard coded in asm/ioctls.h. (Two examples are TIOCGSERIAL and
TIOCSSERIAL for get/set_serial_info). I've grepped for these values,
and don't see anywhere where they are re-defined. Virtually every ioctl
that hits the driver has a bad value.
I can only assume that the results of this are ugly! I'm guessing that
the libraries are compiled with a different convention? Has anyone run
into this issue?
-Chris Hallinan
DS4.COM, Inc.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <20000329001916.D2C3C355E2@elph.research.canon.com.au>]
* Re: ioctl constants
[not found] <20000329001916.D2C3C355E2@elph.research.canon.com.au>
@ 2000-03-29 17:55 ` Chris Hallinan
0 siblings, 0 replies; 2+ messages in thread
From: Chris Hallinan @ 2000-03-29 17:55 UTC (permalink / raw)
To: Graham Stoney, linuxppc-embedded
Graham Stoney wrote:
>
> Hi Chris,
>
> Chris Hallinan writes:
> > I'm using kernel 2.2.13 and a slightly modified version of serial.c to
> > operate an additional 16550 device at a non-standard i/o address.
> ...
> > I've studied the related header files: the constants used in serial.c
> > are hard coded in asm/ioctls.h. (Two examples are TIOCGSERIAL and
> > TIOCSSERIAL for get/set_serial_info). I've grepped for these values,
> > and don't see anywhere where they are re-defined. Virtually every ioctl
> > that hits the driver has a bad value.
>
> OK, here's a completely wild guess for you: is it possible that your
> application is including asm-i386/ioctls.h instead of asm-ppc/ioctls.h?
>
> You should get the right one if your linux/include/asm symlink is set
> correctly and your application goes:
> #include <sys/ioctl.h>
>
> Perhaps somewhere along the line they're getting mixed.
>
> Regards,
> Graham
Thanks for the replies. As it turns out, at least on my system, the
constants in asm-i386/ioctls.h and asm-ppc/ioctls.h are identical. They
define values such as TIOCGSERIAL = 0x541e and TIOCSSERIAL = 0x541f.
The "errant" ioctl() commands hitting the driver look like 0x7413 (I
determined that one is get_serial, and 0x7414 (that one appears to be
set_serial.)
Other unknown cmd values hitting the driver include 0x744d, 0x745a,
0x7451, 0x7459 and 0x744b. It should be possible to determine what
these mean by evaluating the _IOR and _IOW macros, I just haven't had
time to do this.
There appears to be an 'old' and 'new' way to specify these IOCTL
constants. For example:
old TIOCGSERIAL - new TCGETS
old: TIOCSSERIAL - new: TCSETS
I wrote a simple program which uses tcgetattr() and even that sends
"errant" ioctl cmds into my serial.o module.
I'm guessing that someone has figured out a way to make both schemes
work in one system. Any ideas?
-Chris Hallinan
DS4.COM, Inc.
-CLH
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-03-29 17:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-03-28 20:25 ioctl constants Chris Hallinan
[not found] <20000329001916.D2C3C355E2@elph.research.canon.com.au>
2000-03-29 17:55 ` Chris Hallinan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).