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

Re: [bluetooth-dev] kernel mode on ARM+kernel2.4 : ppp problem fixed.



Le Mercredi 07 Mars 2001 15:35, Marcus Smith a écrit :
> I saw a problem back in 2.4.0 (or maybe 2.4.1) where some ioctl commands
> were removed (by
> mistake) from the ppp code in the kernel.  Someone must have realized
> this because the follow-up patch
> included these missing ioctl commands.  This used to give PPP problems.
>
> Are you saying that the default case should NOT forward the ioctl to the
> sertty->driver?

Yes. bt_ioctl should not call sertty->driver->ioctl. That is the job of 
tty_ioctl() (in tty_io.c).

> Is the problem that the driver does not return -ENOIOCTLCMD?

bt_ioctl should return -ENOIOCTLCMD so that tty_ioctl (in tty_io.c) forwards 
that ioctl to the line discipline.

I have done the modification, and it works fine on my system.

>
> Marcus
>
> david LIBAULT wrote:
> > Hi all,
> >
> > I answer to my message myself as nobldy else does ;-)
> >
> > I found a bug in bluetooth.c causing ppp not to work with the stack.
> > In function bt_ioctl, when an ioctl is not "recognised" it is forwarded
> > to the "serial driver". If you remember, this was causing the stack to
> > crash as my serial port didn't support ioctls (the pointer was set to
> > NULL)... So this also causes ppp not to work ! So, I think it should be
> > fixed.
> >
> > Explanations :
> >
> > When pppd opens ttyBT0, it sets its line discipline to N_PPP, and sends
> > ioctls to ttyBT0 destinated to the N_PPP line discipline. When an ioctl
> > is sent to a tty (see in the kernel /drivers/char/tty_io.c), first
> > tty_ioctl is called. If the ioctl is not supported, then
> > tty->driver->ioctl (registered by tty_register_driver), is called (if not
> > NULL which is very nice if your serial driver doesn't implement the ioctl
> > function). If it doesn't support the ioctl, tty->driver->ioctl should
> > return the value -ENOIOCTLCMD (which is not the case for ttyBT0), causing
> > the tty->ldisc->ioctl (in our case from the N_PPP line disc) to be
> > called.
> >
> > So, in bt_ioctl, the default case should return -ENOIOCTLCMD.
> > With this change I could connect the ppp/ip layer.
> > How comes nobody as ever seen this problem ? Is it a tty change beetween
> > older kernel and kernel 2.4 ?
> >
> > David.
> >
> > Le Lundi 05 Mars 2001 11:22, david LIBAULT a écrit :
> >> Hi all,
> >>
> >> When trying to establish a ppp link I get the following problem :
> >>> rf_conn 00:50:CD:11:10:AD 1 0
> >>
> >> Connected.
> >>
> >>> ppp
> >>
> >> Starting modem_emulator
> >> Modem done.
> >> build_pppdopt
> >> pppd
> >> /dev/ttyBT0
> >> 57600
> >> crtscts
> >> debug
> >> local
> >> nodetach
> >> nopersist
> >> silent
> >> passive
> >> noauth
> >> proxyarp
> >> ktune
> >> 10.0.0.1:10.0.0.2
> >> start pppd...
> >> using channel 0
> >> Couldn't attach to channel 0: Device not configured
> >> ppp child died, now restart
> >> Starting modem_emulator
> >>
> >> What is a channel for ppp ? What Device is it complaining about,
> >> /dev/ttyBT0 ?
> >>
> >> David.
> >>
> >> Le Samedi 03 Mars 2001 20:44, david LIBAULT a écrit :
> >>> Hi all,
> >>>
> >>> The UART problem has been fixed (by Russel King). It comes from the
> >>> fact that printk() disables interrupts causing the uart to miss
> >>> bytes... This of course was not happening in user mode ! So changing
> >>> the log level fixes the problem (for the moment).
> >>> I have been able to setup an RF_COMM channel beetween to machines. I
> >>> now have to setup ppp and see if we have the same problem in kernel
> >>> mode than in user mode...
> >>>
> >>> David.
> >>>
> >>> Le Vendredi 02 Mars 2001 22:16, Gordon McNutt a écrit :
> >>>> david LIBAULT wrote:
> >>>>>> 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.
> >>>>
> >>>> Ok, if those addresses look like they make sense to you.
> >>>>
> >>>>> I am checking the serial driver. I am working on an EP7211, and the
> >>>>> serial driver looks loosy...
> >>>>
> >>>> Yes, often these arm archs define their own serial drivers. Sometimes
> >>>> all they want is a console driver so they leave things out...
> >>>>
> >>>> --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
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com