firmware update

Tue Dec 22 20:00:16 PST 2015

Hi Bjorn,

I just tried to update firmware for MC7304 with S2.25N2.35 and SDK SLQS03.03.12, still fail and system report same kernel error log as below:

Dec 23 03:45:09 tvupack kernel: INFO: task slqssdk:1555 blocked for more than 120 seconds.
Dec 23 03:45:09 tvupack kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 23 03:45:09 tvupack kernel: slqssdk         D 0000000000000000     0  1555   1390 0x00000000
Dec 23 03:45:09 tvupack kernel:  ffff8801065ab958 0000000000000086 ffff8801065ab978 ffff8801190eb1a0
Dec 23 03:45:09 tvupack kernel:  ffff8801065abfd8 ffff8801065abfd8 ffff8801065abfd8 0000000000013f40
Dec 23 03:45:09 tvupack kernel:  ffff880119b50000 ffff8801067d9740 ffff8801067d9740 ffff88010fe05968
Dec 23 03:45:09 tvupack kernel: Call Trace:
Dec 23 03:45:09 tvupack kernel:  [<ffffffff816e0669>] schedule+0x29/0x70
Dec 23 03:45:09 tvupack kernel:  [<ffffffff816e091e>] schedule_preempt_disabled+0xe/0x10
Dec 23 03:45:09 tvupack kernel:  [<ffffffff816df597>] __mutex_lock_slowpath+0xd7/0x150
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8151084e>] ? usb_alloc_urb+0x1e/0x50
Dec 23 03:45:09 tvupack kernel:  [<ffffffff816df1aa>] mutex_lock+0x2a/0x50
Dec 23 03:45:09 tvupack kernel:  [<ffffffffa029e10c>] Gobi_dtr_rts+0x6c/0x130 [GobiSerial]
Dec 23 03:45:09 tvupack kernel:  [<ffffffffa03b2725>] ? usb_serial_generic_submit_read_urb+0x25/0x30 [usbserial]
Dec 23 03:45:09 tvupack kernel:  [<ffffffffa03b058f>] serial_dtr_rts+0x7f/0x90 [usbserial]
Dec 23 03:45:09 tvupack kernel:  [<ffffffff81429044>] tty_port_block_til_ready+0x174/0x320
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8107fc10>] ? add_wait_queue+0x60/0x60
Dec 23 03:45:09 tvupack kernel:  [<ffffffffa03b04f2>] ? serial_activate+0x82/0xa0 [usbserial]
Dec 23 03:45:09 tvupack kernel:  [<ffffffff814293eb>] tty_port_open+0xbb/0xe0
Dec 23 03:45:09 tvupack kernel:  [<ffffffff816e159e>] ? _raw_spin_lock+0xe/0x20
Dec 23 03:45:09 tvupack kernel:  [<ffffffffa03b0ad2>] serial_open+0x22/0x30 [usbserial]
Dec 23 03:45:09 tvupack kernel:  [<ffffffff81420fb2>] tty_open+0x172/0x420
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8146848b>] ? kobj_lookup+0x10b/0x170
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8119ff52>] chrdev_open+0xb2/0x1a0
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8119fea0>] ? cdev_put+0x30/0x30
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8119954e>] do_dentry_open+0x21e/0x2a0
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811999c9>] vfs_open+0x49/0x50
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811a7e06>] do_last+0x246/0x820
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8131337c>] ? apparmor_file_alloc_security+0x2c/0x60
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811aa333>] path_openat+0xb3/0x4d0
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811aa776>] ? final_putname+0x26/0x50
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811aa9b9>] ? putname+0x29/0x40
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811ab152>] do_filp_open+0x42/0xa0
Dec 23 03:45:09 tvupack kernel:  [<ffffffff811b8dd5>] ? __alloc_fd+0xe5/0x170
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8119adaa>] do_sys_open+0xfa/0x250
Dec 23 03:45:09 tvupack kernel:  [<ffffffff8119af21>] sys_open+0x21/0x30
Dec 23 03:45:09 tvupack kernel:  [<ffffffff816ea41d>] system_call_fastpath+0x1a/0x1f

About error related with schedule_preempt_disabled, it seems to related to kernel option after review some website. my kernel option is "CONFIG_PREEMPT_VOLUNTARY=y", but CONFIG_PREEMPT is not set, should I set CONFIG_PREEMPT=y?  

I can confirm  this issue don't appear when use the old GobiSerial(NTGR_2.12), but always happen when use Sierra official GobiSerial  driver likes  S2.25N2.35, S2.24N2.33, I guess the issue related to
that DTR is on in new Sierra driver, but not sure very much.

If anyone also have encountered this error, please give me some suggestions?

Thanks

--

Best Regards,
Dai,Lijin

在 2015-12-23 10:17:21，"dailijin" <dailijin126 at 126.com> 写道：

Hi Bjron,

I have added the patch into my qmi_wwan driver, and now I can get QMI response now, and also do QMI connection successfully  via command "qmi-network  /dev/cdc-wdm14 start",
but can not fetch IP via dhclient now. I check the data format which is 'raw-ip', this maybe why I can't get IP. because I remember MC7304 and MC7354  can work before only after I set '802-3' as data format for them. right?

NOTE:

I have upgrade my libqmi from  1.10.2 to 1.12.6.

Thanks

--

Best Regards,
Dai,Lijin

At 2015-12-22 17:58:37, "Bjørn Mork" <bjorn at mork.no> wrote:
>dailijin  <dailijin126 at 126.com> writes:
>
>> Hi All,
>>
>>
>> yes, you are right.  I think the issue should be caused by the
>> GobiSerial driver.
>>
>>
>> if I use the the driver GobiSerial from Sierra S2.24N2.33, the issue
>> will happen. if use the old GobiSerial driver(NTGR_2.12), seems no
>> issue appear, Sorry to send incorrect driver source code, I should
>> send the source code from S2.24N2.33.
>>
>>
>> I know the driver GobiSerial which I am using is not from Sierra, and
>> the newest Sierra driver package should be S2.25N2.35, I want to test
>> it, could you send the source codes to me?
>
>Sure, it's dual GPL/BSD licensed so that should not be a problem.  I'll
>send it in a private mail.  The source is also downloadable from
>Sierra's "source" website.
>
>> Another thing is that I am testing MC7430 modem via libqmi 1.10.2,
>> always can't successfully get QMI response from the modem, I think
>> maybe the libqmi version is old, should I upgrade libqmi version for
>> the modem?
>
>Ah, right. I don't know if there are any relevant libqmi changes yet,
>but 1.10.2 is very old and MC7430 is very new.  That's not a good
>combination in general ;)
>
>The MC74xx modems have some new flow control restrictions which I am
>still trying to figure out.  That's what this is an attempt to solve:
>
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/qmi_wwan.c?id=93725149794d3d418cf1eddcae60c7b536c5faa1
>
>The info comes from the newest Sierra GobiNet drivers. And testing on
>MC7455 showed that the QMI channel will not respond until DTR is on.
>Previously we did not care about DTR at all.  But it appears to have a
>meaning to earlier firmwares too: A DTR off/on sequence has about the
>same effect as sending QMI_CTL SYNC.  Which means that we cannot do DTR
>on/off in the driver based on /dev/cdc-wdmX open/close, since a QMI
>session can be active even if the device is closed.
>
>Then the latest Sierra GobiNet driver (N2.35) added another interesting
>part:
>
>  MODULE_PARM_DESC( iTEEnable, "Enable/Disable TE Flow Control" );
>
>which controls TLV 0x1a of the driver WDS Set Data Format request.  But
>I don't know what that does to the firmware.  I tested it on an EM7305
>and an MC7455, but could not figure out what it is supposed to change.
>Both modems accept the TLV without changing the reply.  The MC7455
>always returns TLV 0x1a = 0x00000000, and the EM7305 doesn't return any
>0x1a TLV (but still accepts it as input).
>
>Writing too much again :) You may not need the latest libqmi, but you
>definitely need the latest drivers for MC74xx modems.
>
>
>
>Bjørn
>_______________________________________________
>libqmi-devel mailing list
>libqmi-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/libqmi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20151223/08d10571/attachment-0001.html>