firmware update
dailijin
dailijin126 at 126.com
Wed Dec 23 00:24:19 PST 2015
Hi David,
Thanks your steps.
I have tested your suggested driver from S2.23N2.30 , and use the newest SDK SLQS03.03.12, the result still fail and report same kernel error.
This is very strange, seems only my system always fail for modem firmware update. As for the kernel error, I guess it caused by CONFIG_PREEMPT is not enable, so could you check kernel option whether CONFIG_PREEMPT is enable on your system? below info is captured from my system:
tvupack tvu # cat /boot/config-3.8.0-23-generic | grep PREEMPT
# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
Thanks
--
Best Regards,
Dai,Lijin
At 2015-12-23 12:26:58, "David McCullough" <david.mccullough at 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 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
>>
>>
>>
>>
>>
>>
>
>--
>David McCullough, david.mccullough at accelerated.com, Ph: 0410 560 763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20151223/fba4c25c/attachment-0001.html>
More information about the libqmi-devel
mailing list