[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Strange uart behavior...



Le Vendredi 02 Mars 2001 21:00, david LIBAULT a écrit :
> Ok, you are probably right. I have checked that the headers are the same
> for the kernel and the module (it is a symbolic link)...
>
> Lets do the following :
>
> I print out the pointers to :
> 	sertty
> 	sertty->driver
> 	sertty->driver.ioctl
> from bluetooth.c
>
> I have to compare that to their value when the line discipline is
> registered right ?

In fact the sertty is set in bt_tty_open which is registered as the line 
discipline of the serial port.
Who is calling bt_ldisc with the (wrong) tty structure at the end ?

>
> Le Vendredi 02 Mars 2001 20:13, Gordon McNutt a écrit :
> > david LIBAULT wrote:
> > > Ok, maybe, the kernel headers are not correct, but the problem doesn't
> > > come from a "bad value" of an ioctl yet. It comes from the
> > > sertty->driver.ioctl function that is not initialized (or initialized
> > > to NULL). So what ever the value of the ioctl would be, it still would
> > > call a "NULL function" with this bad value as its argument...
> >
> > That's exactly what I'm talking about!
> >
> > Forget the ioctl stuff for now, you're right, it's not causing your
> > immediate problem. But consider this: every include file in the bluetooth
> > module (except for those that are explicitly part of the module) will
> > come from a set of kernel headers. Which kernel headers? Well, as you
> > know it depends on a) where your cross-compiler looks by default and b)
> > where your Makefile tells the compiler to look.
> >
> > One of the files which bluetooth.c must include (explictly or implicitly)
> > is <linux/tty_driver.h>. This file defines the layout of struct
> > tty_driver, which contains the ioctl field in question.
> >
> > Say for example that the kernel on your ARM used a version of
> > tty_driver.h that puts the ioctl field at offset 0x60 within the struct.
> > And say that the module is compiling against a version that puts that
> > field at offset 0x24. When the module runs, it's looking in the wrong
> > place for that ioctl call! The serial driver put it someplace else based
> > on the version of tty_driver.h that IT was compiled against.
> >
> > Now, since that value is NULL, and you changed the code to not call it if
> > it's NULL, then you'll never setup the baud rate, parity, raw mode, etc
> > that you need to. That's probably why your UART data looks hosed.
> >
> > That's why it's important that, when compiling a module, you do it
> > against the same set of kernel headers that the kernel was compiled
> > against. It sure looks like this could be your problem. But if this was
> > your problem, I'd expect insmod to complain about the version mismatch...
> >
> > --gmcnutt
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe bluetooth-dev"
> > in the body of a message to majordomo@xxxxxxx.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com