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

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

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 :
from bluetooth.c

I have to compare that to their value when the line discipline is registered 
right ?

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