<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Hi David,</div><div><br></div><div>Thanks your steps.</div><div><br></div><div>I have tested your suggested driver from <span style="font-family: arial; line-height: 23.324px; white-space: pre-wrap;">S2.23N2.30 , and use the newest SDK </span><span style="font-family: arial; line-height: 23.8px; white-space: pre-wrap;">SLQS03.03.12, the result still fail and report same kernel error. </span></div><div>This is very strange, seems only my system always fail for modem firmware update. As for the kernel error, I guess it caused by <span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12.8px; line-height: normal;">CONFIG_PREEMPT is not enable, so</span><span style="line-height: 1.7;"> </span><span style="line-height: 1.7;">could you check kernel option whether </span><span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12.8px; line-height: normal;">CONFIG_PREEMPT is enable on your system? below info is captured from my system:</span></div><div><span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12.8px; line-height: normal;"><br></span></div><div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;">tvupack tvu # cat /boot/config-3.8.0-23-generic | grep PREEMPT </span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;"># CONFIG_PREEMPT_RCU is not set</span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;">CONFIG_PREEMPT_NOTIFIERS=y</span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;"># CONFIG_PREEMPT_NONE is not set</span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;">CONFIG_PREEMPT_VOLUNTARY=y</span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;"># CONFIG_PREEMPT is not set</span></font></div></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;"><br></span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;"><br></span></font></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size: 12.8px; line-height: normal;">Thanks</span></font></div><br><br><br><br><div style="position:relative;zoom:1">--<br><div>
<div style="FONT-SIZE: 14px">
<div align="left"><strong><font color="#0000ff"><em>Best Regards,</em></font></strong></div>
<div><strong><font color="#0000ff"><em>Dai,Lijin</em></font></strong></div></div></div><div style="clear:both"></div></div><div id="divNeteaseMailCard"></div><br><pre><br>At 2015-12-23 12:26:58, "David McCullough" <david.mccullough@accelerated.com> wrote:
>
>
>dailijin wrote the following:
>> 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:
>
>
>I have been sort of following so I thought is was time I put up some info
>in case it helps.
>
>We are programming 7304/7354 modems with using the following versions:
>
>GobiSerial: 2015-03-09/SWI_2.23
>GobiNet: 2015-03-09/SWI_2.30
>
>The sources were obtained from:
>
> SierraLinuxQMIdriversS2.23N2.30.tar.bz2
>
>No changes were used.
>
>The SDK we are using is:
>
> SLQS03.03.06.bin.tar.gz
>
>I have programmed hundreds on modems with this combination, but, it took
>a while to find a process that gave a good rate of success. We use the 2
>file process to save on space (common files) so I am not sure iof
>into smaller chu
>
> 1. black list linux drivers and unload them
>
> 2. load the Gobi* drivers
>
> 3. reset the modem[*]
> wait for it to return
>
> 4. start/restart slqssdk
>
> 5. load the NVU image is noit already done with
> mc7xxximgtool -n <firmware-dir>
> on failure goto 3
>
> 6. load CWE is not already loaded with
> mc7xxximgtool -f <firmware-dir>
> on failure goto 3
>
> 7. dump settings with
> mc7xxximgtool -i
>
>
> [*] send 'at!greset' on command tty (ttyUSB2 on our single modem systems)
> if that does not return OK, do a 'usbreset /dev/bus/usb...'
>
>I rarely if ever make it through a full program without a reset of some
>kind, and thats not including the reset done by the programming process.
>
>Seems clunky I know but with the number of HW restarts and drivers swapping
>I found things tended to get mixed up or confused fairly regularly.
>
>Hope this helps somehow ;-)
>
>
>Cheers,
>Davidm
>
>
>>
>> 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@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@mork.no> wrote:
>> >dailijin <dailijin126@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@lists.freedesktop.org
>> >http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>>
>>
>>
>>
>>
>>
>
>--
>David McCullough, david.mccullough@accelerated.com, Ph: 0410 560 763
</pre></div><br><br><span title="neteasefooter"><p> </p></span>