Hello,
commit 4a90f09b20f4622dcbff1f0e1e6bae1704f8ad8c
tty: usb-serial krefs
Use kref in the USB serial drivers so that we don't free tty structures
from under the URB receive handlers as has historically been the case if
you were unlucky. This also gives us a framework for general tty drivers to
use tty_port objects and refcount.
Contains two err->dev_err changes merged together to fix clashes in the
-next tree.
Signed-off-by: Alan Cox <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
----
causes problems with my usb hsdpa modem. when I try to connect pppd
dies and I get these messages on dmesg:
[...]
usb-storage: device scan complete
PPP generic driver version 2.4.2
bad magic number for tty struct (188:0) in tty_ioctl
bad magic number for tty struct (188:0) in tty_ioctl
bad magic number for tty struct (188:0) in tty_release_dev
bad magic number for tty struct (188:0) in tty_poll
bad magic number for tty struct (188:0) in tty_poll
bad magic number for tty struct (188:0) in tty_write
bad magic number for tty struct (188:0) in tty_ioctl
bad magic number for tty struct (188:0) in tty_ioctl
bad magic number for tty struct (188:0) in tty_ioctl
bad magic number for tty struct (188:0) in tty_release_dev
---
drivers/usb/serial/ChangeLog.history has this:
(03/26/2002) gkh
removed the port->tty check from port_paranoia_check() due to serial
consoles not having a tty device assigned to them.
and this seems to be the problem here.
something in this commit seems to make it reach the tty_paranoia_check
in tty_ioctl() from drivers/char/tty_io.c, but I could be completely
wrong.
Sergio.
On Sat, Oct 18, 2008 at 1:15 PM, Sergio Luis <[email protected]> wrote:
> Hello,
>
> commit 4a90f09b20f4622dcbff1f0e1e6bae1704f8ad8c
>
> tty: usb-serial krefs
>
> Use kref in the USB serial drivers so that we don't free tty structures
> from under the URB receive handlers as has historically been the case if
> you were unlucky. This also gives us a framework for general tty drivers to
> use tty_port objects and refcount.
>
> Contains two err->dev_err changes merged together to fix clashes in the
> -next tree.
>
> Signed-off-by: Alan Cox <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> ----
>
> causes problems with my usb hsdpa modem. when I try to connect pppd
> dies and I get these messages on dmesg:
>
> [...]
> usb-storage: device scan complete
> PPP generic driver version 2.4.2
> bad magic number for tty struct (188:0) in tty_ioctl
> bad magic number for tty struct (188:0) in tty_ioctl
> bad magic number for tty struct (188:0) in tty_release_dev
> bad magic number for tty struct (188:0) in tty_poll
> bad magic number for tty struct (188:0) in tty_poll
> bad magic number for tty struct (188:0) in tty_write
> bad magic number for tty struct (188:0) in tty_ioctl
> bad magic number for tty struct (188:0) in tty_ioctl
> bad magic number for tty struct (188:0) in tty_ioctl
> bad magic number for tty struct (188:0) in tty_release_dev
>
> ---
>
> drivers/usb/serial/ChangeLog.history has this:
>
> (03/26/2002) gkh
> removed the port->tty check from port_paranoia_check() due to serial
> consoles not having a tty device assigned to them.
>
> and this seems to be the problem here.
> something in this commit seems to make it reach the tty_paranoia_check
> in tty_ioctl() from drivers/char/tty_io.c, but I could be completely
> wrong.
>
> Sergio.
>
Hello,
one of the problems was the tty_kref_put(tty) in
usb_serial_port_work() [drivers/usb/serial/usb-serial.c], that was
releasing the tty device. I removed that line and it _almost_ worked.
well, it worked, but only _once_. If I stopped the daemon and tried to
start it again, it would give me I/O error and would not open
/dev/ttyUSB0 anymore.
I'd suggest to revert that commit and to review it more carefully.
What do you people think?
Thanks,
Sergio.
> I'd suggest to revert that commit and to review it more carefully.
> What do you people think?
I suggest you demonstrate a little patience. Its a weekend, its a bug
that seems specific to a single device and we've got a ton of time to
nail it.
I'll take a look Tuesday and I don't expect it to take long to pin down -
there will be an unbalanced kref_put somewhere.
Alan
> one of the problems was the tty_kref_put(tty) in
> usb_serial_port_work() [drivers/usb/serial/usb-serial.c], that was
> releasing the tty device. I removed that line and it _almost_ worked.
> well, it worked, but only _once_. If I stopped the daemon and tried to
You removed a valid one not the erroneous one it seems.
Unfortunately your bug report doesn't actually say _WHICH_ USB serial
driver you are using which makes it a bit hard to be sure I'm looking for
the right bug.
On Tue, Oct 21, 2008 at 9:38 AM, Alan Cox <[email protected]> wrote:
>> one of the problems was the tty_kref_put(tty) in
>> usb_serial_port_work() [drivers/usb/serial/usb-serial.c], that was
>> releasing the tty device. I removed that line and it _almost_ worked.
>> well, it worked, but only _once_. If I stopped the daemon and tried to
>
> You removed a valid one not the erroneous one it seems.
>
> Unfortunately your bug report doesn't actually say _WHICH_ USB serial
> driver you are using which makes it a bit hard to be sure I'm looking for
> the right bug.
>
The device is a Huawei E220 USB modem. What kind of info can I provide
to help you with this? would dmesg help?
Sergio.
On Tue, 21 Oct 2008 09:42:47 -0300
"Sergio Luis" <[email protected]> wrote:
> On Tue, Oct 21, 2008 at 9:38 AM, Alan Cox <[email protected]> wrote:
> >> one of the problems was the tty_kref_put(tty) in
> >> usb_serial_port_work() [drivers/usb/serial/usb-serial.c], that was
> >> releasing the tty device. I removed that line and it _almost_ worked.
> >> well, it worked, but only _once_. If I stopped the daemon and tried to
> >
> > You removed a valid one not the erroneous one it seems.
> >
> > Unfortunately your bug report doesn't actually say _WHICH_ USB serial
> > driver you are using which makes it a bit hard to be sure I'm looking for
> > the right bug.
> >
>
> The device is a Huawei E220 USB modem. What kind of info can I provide
> to help you with this? would dmesg help?
Ok thanks. Thats useful for two reasons
1. I've sent Linus a patch which I think fixes it
2. I have an E220 as well and mine now behaves
Alan