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

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



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?
Is the problem that the driver does not return -ENOIOCTLCMD?

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