Re: Slow mobile broadband detection



On Wed, 2011-06-15 at 08:10 +0200, dave guandalino wrote:
> > Except that patch only works for the 'option' driver, which is where
> > most 3G modem USB IDs should be added.  If your device's IDs aren't
> > there, you can't take advantage of the fix.  What are your device's IDs?
> 
> Well. How can I determine them and check if they are present or not?
> 
> Btw, the 'option' driver gets loaded.
> $ lsmod | grep option
> option                 25285  2
> usb_wwan               20407  1 option
> usbserial              42908  7 option,usb_wwan

Ok, so this probably indicates that we need to add your device to the
"sendsetup" quirk.  If you run "lsusb" and find your device you'll get
something like:

Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810

Then grab full lsusb output like so:

lsusb -v -d 08ff:2810

then we can go about doing that.

Dan

> $ modinfo option
> filename:
> /lib/modules/2.6.38-8-generic/kernel/drivers/usb/serial/option.ko
> license:        GPL
> version:        v0.7.2
> description:    USB Driver for GSM modems
> author:         Matthias Urlichs <smurf smurf noris de>
> srcversion:     0D74972353E56E42A1951FF
> alias:          usb:v1EE8p000Bd*dc*dsc*dp*ic*isc*ip*
> ...a lot of other alias lines...
> 
> >
> > Dan
> >
> >>
> >> >
> >> > Perazim
> >> >
> >> > On Thu, 2011-05-12 at 21:29 +0100, perazim portugalmail pt wrote:
> >> >>
> >> >> Dan,
> >> >>
> >> >> Attached are the messages log and the modem-manager log for the Alcatel
> >> >> X220.
> >> >>
> >> >> Let me know if you need any other info or to test anything.
> >> >
> >> > These logs indicate a kernel bug, with a 30 second hang when closing a
> >> > serial port.  I submitted a patch to the kernel to fix this issue which
> >> > was accepted for the 2.6.37 kernel:
> >> >
> >> > commit 02303f73373aa1da19dbec510ec5a4e2576f9610
> >> > Author: Dan Williams <dcbw redhat com>
> >> > Date:   Fri Nov 19 16:04:00 2010 -0600
> >> >
> >> >    usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking
> >> > close(2)
> >> >
> >> >    Some devices (ex ZTE 2726) simply don't respond at all when data is sent
> >> >    to some of their USB interfaces.  The data gets stuck in the TTYs queue
> >> >    and sits there until close(2), which them blocks because closing_wait
> >> >    defaults to 30 seconds (even though the fd is O_NONBLOCK).  This is
> >> >    rarely desired.  Implement the standard mechanism to adjust closing_wait
> >> >    and let applications handle it how they want to.
> >> >
> >> >    Signed-off-by: Dan Williams <dcbw redhat com>
> >> >
> >> > and the ModemManager snapshot you have should have the support necessary
> >> > here.  What kernel version are you running?
> >> >
> >> > Dan
> >> >
> >> > _______________________________________________
> >> > networkmanager-list mailing list
> >> > networkmanager-list gnome org
> >> > http://mail.gnome.org/mailman/listinfo/networkmanager-list
> >> >
> >> _______________________________________________
> >> networkmanager-list mailing list
> >> networkmanager-list gnome org
> >> http://mail.gnome.org/mailman/listinfo/networkmanager-list
> >
> >
> >




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