[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] Strange uart behavior...
Le Vendredi 02 Mars 2001 21:26, Gordon McNutt a écrit :
> david LIBAULT wrote:
> > 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)...
> Symbolic link from where to where? /usr/include/linux to
> /usr/src/linux/include? Even if you are compiling natively this isn't
> necessarily valid unless the kernel you're running matches that source
All the files that make up bt.o are built with the -I /usr/arm-linux/include
In the /usr/arm-linux/include directory I have a symbolic link called linux
to the include/linux directrory of the kernel sources that I have cross
> And if you are cross-compiling then this is almost sure to be the wrong
> kernel source tree. Furthermore, most cross-compilers will look someplace
> else first before /usr/include/linux to find the kernel headers! This is a
> "feature" which makes sense for cross-compiling apps & libs but not
> necessarily helpful for kernel & module development.
> Are you compiling natively on the ARM or cross-compiling?
I am cross-compile. Don't worry, if I leave the cross-compiler build with the
/usr/include/linux directory, nothing would build (asm code in some
> If you add the -H flag to gcc you can see where it's pulling headers from.
> > > 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 ?
> If my theory is correct then sertty->driver.ioctl will be munged up (from
> the modules's perspective) all the time -- even at registration.
Well, it is not :
sertty : 0xc04e8000
sertty->driver : 0xc04e8004
sertty->driver.ioctl : 0xc04e8080 (at this address the value is 0)
These values look good to me, considering the start address of the DRAM, and
the shape of the structure.
> > 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 ?
> drivers/char/tty_io.c. And it probably thinks the tty structure looks just
> fine! Because it was compiled with the same kernel headers as serial.c.
I am checking the serial driver. I am working on an EP7211, and the serial
driver looks loosy...
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com