Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem
On Sun, 2012-02-26 at 19:48 +0100, Maik Zumstrull wrote:
> On Sun, Feb 26, 2012 at 18:57, Greg KH <greg@kroah.com> wrote:
> > On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote:
>
> >> > Is the device stuck doing something?
> >>
> >> Not as far as I know.
> >
> > Are two userspace programs trying to access the device at the same time?
>
> The device exports three virtual serial ports. ModemManager accesses
> more than one. On the other hand, we were able to reproduce the freeze
> accessing only one port from one process, see Bugzilla.
>
> I've attached a fresh strace of opening the device on 3.2.6. The
> open() takes 10s, the close takes 5s. Nothing else was accessing any
> ttyUSB*; I killed ModemManager and double checked with lsof.
>
> > Yes. Please try loading the module with:
> > modprobe option debug=1
> > and seeing what happens in the kernel log when you open the device.
>
> Output attached. I think it's three "option_send_setup" for one
> open()/close(). At least, that's what happens with the C snippet.
There's a few issues going on here that I've seen before. First is the
SENDSETUP quirk in option.ko that is required for some devices where the
interface is claimed by option but really isn't supposed to be, because
it's not actually speaking USB serial. Thus it doesn't respond to the
sendsetup command and the option driver just blocks for a bit.
Second is "closing_wait", which ModemManager sets to
ASYNC_CLOSING_WAIT_NONE to prevent a 5 or 10 second freeze on close()
where if the port has not responded to any request, the buffer is still
full, and close() blocks (even if O_NONBLOCK) until the buffer is
flushed. Setting ASYNC_CLOSING_WAIT_NONE appeared to fix that.
What device is this?
Dan
Reply to: