6:31 a.m.
Hi all,
I'm trying to connect with a Huawei E226, but I'm getting
different behavior whether I start ofonod with the modem (USB) plugged in or
not:
Scenario 1:
1 - start ofonod
2 - plug the modem
3 - not working
Log: huawei-connected.log (attached)
Scenario 2:
1 - start ofonod
2 - plug the modem
3 - call disable-modem
4 - call enable-modem
5 - it works
Log: huawei-testscripts.log
Scenario 3:
1 - plug the modem
2 - start ofonod
3 - it works
Log file: huawei-not-connected.log
I'm testing with MeeGo, ofono from git and connman 0.57.
thanks,
Thiago
11:45 a.m.
Hi Thiago,
On 08/17/2010 03:31 PM, Thiago Cangussu de Castro Gomes wrote:
Hi all,
I'm trying to connect with a Huawei E226, but I'm getting
different behavior whether I start ofonod with the modem (USB) plugged
in or not:
Scenario 1:
1 - start ofonod
2 - plug the modem
3 - not working
Log: huawei-connected.log (attached)
Scenario 2:
1 - start ofonod
2 - plug the modem
3 - call disable-modem
4 - call enable-modem
5 - it works
Log: huawei-testscripts.log
Scenario 3:
1 - plug the modem
2 - start ofonod
3 - it works
Log file: huawei-not-connected.log
I'm testing with MeeGo, ofono from git and connman 0.57.
The problem with the failed cases it that oFono / ConnMan combination is
simply too fast. It tries to access the Modem before it had the chance
to properly initialize the SIM card. We have pushed some fixes upstream
after the 0.26 release that should alleviate this.
Regards,
-Denis
12:06 a.m.
On Tue, Aug 17, 2010 at 10:45 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
> I'm trying to connect with a Huawei E226, but I'm getting
> different behavior whether I start ofonod with the modem (USB) plugged
> in or not:
>
> Scenario 1:
>
> 1 - start ofonod
> 2 - plug the modem
> 3 - not working
>
> Log: huawei-connected.log (attached)
>
> Scenario 2:
>
> 1 - start ofonod
> 2 - plug the modem
> 3 - call disable-modem
> 4 - call enable-modem
> 5 - it works
>
> Log: huawei-testscripts.log
>
> Scenario 3:
>
> 1 - plug the modem
> 2 - start ofonod
> 3 - it works
>
> Log file: huawei-not-connected.log
>
> I'm testing with MeeGo, ofono from git and connman 0.57.
The problem with the failed cases it that oFono / ConnMan combination is
simply too fast. It tries to access the Modem before it had the chance
to properly initialize the SIM card. We have pushed some fixes upstream
after the 0.26 release that should alleviate this.
Thanks for the response. You are right, I can reproduce the problem
even with connman turned off, by calling the test scripts before the
modem is ready.
I'm using both ofono and connman from git, with all the available
updates so far. Does it mean that the fixes didn't solved the issue in
my case? Could you point me to the patches?
Thanks,
Thiago
3:02 a.m.
Hi Thiago,
> The problem with the failed cases it that oFono / ConnMan
combination is
> simply too fast. It tries to access the Modem before it had the chance
> to properly initialize the SIM card. We have pushed some fixes upstream
> after the 0.26 release that should alleviate this.
Thanks for the response. You are right, I can reproduce the problem
even with connman turned off, by calling the test scripts before the
modem is ready.
I'm using both ofono and connman from git, with all the available
updates so far. Does it mean that the fixes didn't solved the issue in
my case? Could you point me to the patches?
For your particular case these patches from Kalle would be helpful:
[PATCH 1/2] huawei: poll sim state
[PATCH 2/2] huawei: postpone post_sim until SIM is ready
However, they weren't integrated upstream due to some concerns. See the
entire thread for more details.
Regards,
-Denis
8:26 a.m.
On Wed, Aug 18, 2010 at 2:02 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
Hi Thiago,
>> The problem with the failed cases it that oFono / ConnMan combination is
>> simply too fast. It tries to access the Modem before it had the chance
>> to properly initialize the SIM card. We have pushed some fixes upstream
>> after the 0.26 release that should alleviate this.
>
> Thanks for the response. You are right, I can reproduce the problem
> even with connman turned off, by calling the test scripts before the
> modem is ready.
>
> I'm using both ofono and connman from git, with all the available
> updates so far. Does it mean that the fixes didn't solved the issue in
> my case? Could you point me to the patches?
For your particular case these patches from Kalle would be helpful:
[PATCH 1/2] huawei: poll sim state
[PATCH 2/2] huawei: postpone post_sim until SIM is ready
However, they weren't integrated upstream due to some concerns. See the
entire thread for more details.
I've applied the patches but unfortunately it didn't fixed the issue.
Still can't connect when the modem is plugged after ofonod is started.
I can send the logs if anyone thinks it's useful.
Regards,
Thiago
8:31 a.m.
Hi Thiago,
On 08/18/2010 05:26 PM, Thiago Cangussu de Castro Gomes wrote:
On Wed, Aug 18, 2010 at 2:02 PM, Denis Kenzior
<denkenz(a)gmail.com> wrote:
> Hi Thiago,
>
>>> The problem with the failed cases it that oFono / ConnMan combination is
>>> simply too fast. It tries to access the Modem before it had the chance
>>> to properly initialize the SIM card. We have pushed some fixes upstream
>>> after the 0.26 release that should alleviate this.
>>
>> Thanks for the response. You are right, I can reproduce the problem
>> even with connman turned off, by calling the test scripts before the
>> modem is ready.
>>
>> I'm using both ofono and connman from git, with all the available
>> updates so far. Does it mean that the fixes didn't solved the issue in
>> my case? Could you point me to the patches?
>
> For your particular case these patches from Kalle would be helpful:
>
> [PATCH 1/2] huawei: poll sim state
> [PATCH 2/2] huawei: postpone post_sim until SIM is ready
>
> However, they weren't integrated upstream due to some concerns. See the
> entire thread for more details.
I've applied the patches but unfortunately it didn't fixed the issue.
Still can't connect when the modem is plugged after ofonod is started.
I can send the logs if anyone thinks it's useful.
Sorry to hear you're having trouble. Kalle reported similar issues were
fixed with his patches on the E1552. Sending the logs would probably be
helpful.
Regards,
-Denis
6:25 a.m.
On Wed, Aug 18, 2010 at 7:31 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
>> For your particular case these patches from Kalle would be
helpful:
>>
>> [PATCH 1/2] huawei: poll sim state
>> [PATCH 2/2] huawei: postpone post_sim until SIM is ready
>>
>> However, they weren't integrated upstream due to some concerns. See the
>> entire thread for more details.
>
> I've applied the patches but unfortunately it didn't fixed the issue.
> Still can't connect when the modem is plugged after ofonod is started.
> I can send the logs if anyone thinks it's useful.
>
Sorry to hear you're having trouble. Kalle reported similar issues were
fixed with his patches on the E1552. Sending the logs would probably be
helpful.
Here are (attached) the logs. I turned off connman. The two tests scenarios are:
Test A (connect-modem-after-fast.log)
- start ofono
- plug the modem
- call enable-modem just after inserting the modem
Test B (connect-modem-after-slow.log)
- start ofono
- plug the modem
- wait until the modem led switches from green to blue
- call enable-modem after some seconds
The second scenario is what happens when connmand is running, and is
the most common use case: someone plugs in the modem with the system
running.
Regards,
Thiago
8:16 a.m.
Hi Thiago,
On 08/24/2010 03:25 PM, Thiago Cangussu de Castro Gomes wrote:
On Wed, Aug 18, 2010 at 7:31 PM, Denis Kenzior
<denkenz(a)gmail.com> wrote:
>>> For your particular case these patches from Kalle would be helpful:
>>>
>>> [PATCH 1/2] huawei: poll sim state
>>> [PATCH 2/2] huawei: postpone post_sim until SIM is ready
>>>
>>> However, they weren't integrated upstream due to some concerns. See the
>>> entire thread for more details.
>>
>> I've applied the patches but unfortunately it didn't fixed the issue.
>> Still can't connect when the modem is plugged after ofonod is started.
>> I can send the logs if anyone thinks it's useful.
>>
>
> Sorry to hear you're having trouble. Kalle reported similar issues were
> fixed with his patches on the E1552. Sending the logs would probably be
> helpful.
Here are (attached) the logs. I turned off connman. The two tests scenarios are:
Test A (connect-modem-after-fast.log)
- start ofono
- plug the modem
- call enable-modem just after inserting the modem
Test B (connect-modem-after-slow.log)
- start ofono
- plug the modem
- wait until the modem led switches from green to blue
- call enable-modem after some seconds
The second scenario is what happens when connmand is running, and is
the most common use case: someone plugs in the modem with the system
running.
It seems you forgot to include the actual logs.
Regards,
-Denis
8:58 a.m.
On Tue, Aug 24, 2010 at 7:16 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
Hi Thiago,
On 08/24/2010 03:25 PM, Thiago Cangussu de Castro Gomes wrote:
> On Wed, Aug 18, 2010 at 7:31 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
>>>> For your particular case these patches from Kalle would be helpful:
>>>>
>>>> [PATCH 1/2] huawei: poll sim state
>>>> [PATCH 2/2] huawei: postpone post_sim until SIM is ready
>>>>
>>>> However, they weren't integrated upstream due to some concerns. See
the
>>>> entire thread for more details.
>>>
>>> I've applied the patches but unfortunately it didn't fixed the
issue.
>>> Still can't connect when the modem is plugged after ofonod is started.
>>> I can send the logs if anyone thinks it's useful.
>>>
>>
>> Sorry to hear you're having trouble. Kalle reported similar issues were
>> fixed with his patches on the E1552. Sending the logs would probably be
>> helpful.
>
> Here are (attached) the logs. I turned off connman. The two tests scenarios are:
>
> Test A (connect-modem-after-fast.log)
>
> - start ofono
> - plug the modem
> - call enable-modem just after inserting the modem
>
> Test B (connect-modem-after-slow.log)
>
> - start ofono
> - plug the modem
> - wait until the modem led switches from green to blue
> - call enable-modem after some seconds
>
> The second scenario is what happens when connmand is running, and is
> the most common use case: someone plugs in the modem with the system
> running.
It seems you forgot to include the actual logs.
Let me try again :)
I forgot also to mention that I used list-context to see if the
enable-modem was successful. The test B is the one that fails.
Regards,
Thiago
9:45 a.m.
Hi Thiago,
On 08/24/2010 05:58 PM, Thiago Cangussu de Castro Gomes wrote:
On Tue, Aug 24, 2010 at 7:16 PM, Denis Kenzior
<denkenz(a)gmail.com> wrote:
> Hi Thiago,
>
> On 08/24/2010 03:25 PM, Thiago Cangussu de Castro Gomes wrote:
>> On Wed, Aug 18, 2010 at 7:31 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
>>>>> For your particular case these patches from Kalle would be helpful:
>>>>>
>>>>> [PATCH 1/2] huawei: poll sim state
>>>>> [PATCH 2/2] huawei: postpone post_sim until SIM is ready
>>>>>
>>>>> However, they weren't integrated upstream due to some concerns.
See the
>>>>> entire thread for more details.
>>>>
>>>> I've applied the patches but unfortunately it didn't fixed the
issue.
>>>> Still can't connect when the modem is plugged after ofonod is
started.
>>>> I can send the logs if anyone thinks it's useful.
>>>>
>>>
>>> Sorry to hear you're having trouble. Kalle reported similar issues were
>>> fixed with his patches on the E1552. Sending the logs would probably be
>>> helpful.
>>
>> Here are (attached) the logs. I turned off connman. The two tests scenarios are:
>>
>> Test A (connect-modem-after-fast.log)
>>
>> - start ofono
>> - plug the modem
>> - call enable-modem just after inserting the modem
>>
>> Test B (connect-modem-after-slow.log)
>>
>> - start ofono
>> - plug the modem
>> - wait until the modem led switches from green to blue
>> - call enable-modem after some seconds
>>
>> The second scenario is what happens when connmand is running, and is
>> the most common use case: someone plugs in the modem with the system
>> running.
>
> It seems you forgot to include the actual logs.
Let me try again :)
I forgot also to mention that I used list-context to see if the
enable-modem was successful. The test B is the one that fails.
From the logs it seems Test A is what fails since we never add any
atoms
in that one. Basically the problem is that your modem firmware never
tells us that the SIM has been initialized by sending us a ^SIMST
notification.
Kalle's patch relies on SIMST being delivered eventually. Since it
never does, oFono is under the impression that your SIM is invalid. We
probably need to query SYSINFO a few more times in this case, but it
seems all Huawei firmwares act slightly differently here.
Regards,
-Denis
7:24 a.m.
On Tue, Aug 24, 2010 at 8:45 PM, Denis Kenzior <denkenz(a)gmail.com> wrote:
> Let me try again :)
>
> I forgot also to mention that I used list-context to see if the
> enable-modem was successful. The test B is the one that fails.
From the logs it seems Test A is what fails since we never add any atoms
in that one. Basically the problem is that your modem firmware never
tells us that the SIM has been initialized by sending us a ^SIMST
notification.
Kalle's patch relies on SIMST being delivered eventually. Since it
never does, oFono is under the impression that your SIM is invalid. We
probably need to query SYSINFO a few more times in this case, but it
seems all Huawei firmwares act slightly differently here.
Is there something else I can do to help solve this issue? I tried
another modem, a ZTE MF110, that is not working either. I installed
wvdial on my MeeGo machine and was able to connect using both the
Huawei and ZTE modems. I also tested the devices under Ubuntu Lucid
and Fedora 13 (both with Networkmanager) and they worked out of the
box.
Those devices are supplied by some of the major wireless carriers here
in Brazil, so it would be nice to have them working with ofono/MeeGo.
Thanks,
Thiago
6:02 p.m.
Hi Thiago,
>> I forgot also to mention that I used list-context to see if
the
>> enable-modem was successful. The test B is the one that fails.
>
> From the logs it seems Test A is what fails since we never add any atoms
> in that one. Basically the problem is that your modem firmware never
> tells us that the SIM has been initialized by sending us a ^SIMST
> notification.
>
> Kalle's patch relies on SIMST being delivered eventually. Since it
> never does, oFono is under the impression that your SIM is invalid. We
> probably need to query SYSINFO a few more times in this case, but it
> seems all Huawei firmwares act slightly differently here.
Is there something else I can do to help solve this issue? I tried
another modem, a ZTE MF110, that is not working either. I installed
wvdial on my MeeGo machine and was able to connect using both the
Huawei and ZTE modems. I also tested the devices under Ubuntu Lucid
and Fedora 13 (both with Networkmanager) and they worked out of the
box.
the problem is that neither wvdial nor NM are proper telephony stacks.
They are both in the end just dialers. So that comparison is not helping
us since oFono has to do way more work before we can just "dial" an
Internet connection.
We get this fixed, but not as quick as you might like us too. The Huawei
and ZTE modems are showing race condition behavior. And that is mainly
because oFono is just too fast and they can't initialize the SIM fast
enough for us.
Regards
Marcel
10:58 p.m.
Hi Marcel,
On Fri, Aug 27, 2010 at 5:02 AM, Marcel Holtmann <marcel(a)holtmann.org> wrote:
Hi Thiago,
> >> I forgot also to mention that I used list-context to see if the
> >> enable-modem was successful. The test B is the one that fails.
> >
> > From the logs it seems Test A is what fails since we never add any atoms
> > in that one. Basically the problem is that your modem firmware never
> > tells us that the SIM has been initialized by sending us a ^SIMST
> > notification.
> >
> > Kalle's patch relies on SIMST being delivered eventually. Since it
> > never does, oFono is under the impression that your SIM is invalid. We
> > probably need to query SYSINFO a few more times in this case, but it
> > seems all Huawei firmwares act slightly differently here.
>
> Is there something else I can do to help solve this issue? I tried
> another modem, a ZTE MF110, that is not working either. I installed
> wvdial on my MeeGo machine and was able to connect using both the
> Huawei and ZTE modems. I also tested the devices under Ubuntu Lucid
> and Fedora 13 (both with Networkmanager) and they worked out of the
> box.
the problem is that neither wvdial nor NM are proper telephony stacks.
They are both in the end just dialers. So that comparison is not helping
us since oFono has to do way more work before we can just "dial" an
Internet connection.
We get this fixed, but not as quick as you might like us too. The Huawei
and ZTE modems are showing race condition behavior. And that is mainly
because oFono is just too fast and they can't initialize the SIM fast
enough for us.
I understand. I mixed up two problems and that got confusing. The ZTE
modem is not showing the race condition issue. It didn't showed up
when I called list-modems. That is why I tested it with other
software, just to be sure it works with linux (MeeGo in this case). I
will test again with the ZTE modem and send the logs to the list.
I am reading the code and some specs from 3GPP, but it's all new stuff
to me and you will probably fix this before I can even understand what
is really going on :) For now I'll keep testing the new code and
sending the logs to the list.
Regards,
Thiago
4:14 a.m.
Hi Thiago,
>> >> I forgot also to mention that I used list-context
to see if the
>> >> enable-modem was successful. The test B is the one that fails.
>> >
>> > From the logs it seems Test A is what fails since we never add any atoms
>> > in that one. Basically the problem is that your modem firmware never
>> > tells us that the SIM has been initialized by sending us a ^SIMST
>> > notification.
>> >
>> > Kalle's patch relies on SIMST being delivered eventually. Since it
>> > never does, oFono is under the impression that your SIM is invalid. We
>> > probably need to query SYSINFO a few more times in this case, but it
>> > seems all Huawei firmwares act slightly differently here.
>>
>> Is there something else I can do to help solve this issue? I tried
>> another modem, a ZTE MF110, that is not working either. I installed
>> wvdial on my MeeGo machine and was able to connect using both the
>> Huawei and ZTE modems. I also tested the devices under Ubuntu Lucid
>> and Fedora 13 (both with Networkmanager) and they worked out of the
>> box.
>
> the problem is that neither wvdial nor NM are proper telephony stacks.
> They are both in the end just dialers. So that comparison is not helping
> us since oFono has to do way more work before we can just "dial" an
> Internet connection.
>
> We get this fixed, but not as quick as you might like us too. The Huawei
> and ZTE modems are showing race condition behavior. And that is mainly
> because oFono is just too fast and they can't initialize the SIM fast
> enough for us.
I understand. I mixed up two problems and that got confusing. The ZTE
modem is not showing the race condition issue. It didn't showed up
when I called list-modems. That is why I tested it with other
software, just to be sure it works with linux (MeeGo in this case). I
will test again with the ZTE modem and send the logs to the list.
my ZTE modem works, but you need the latest oFono and its udev rules to
make it detect.
Regards
Marcel
4:57 a.m.
> I understand. I mixed up two problems and that got confusing. The
ZTE
> modem is not showing the race condition issue. It didn't showed up
> when I called list-modems. That is why I tested it with other
> software, just to be sure it works with linux (MeeGo in this case). I
> will test again with the ZTE modem and send the logs to the list.
my ZTE modem works, but you need the latest oFono and its udev rules to
make it detect.
I'm using ofono from git (last commit from yesterday) and the udev
rules are installed and loaded. The ZTE is a MF110.
When I plug the device, I need to call eject /dev/sr0, only after that
it is recognized correctly. After that, the following appears on ofono
log:
ofonod[1632]: src/modem.c:ofono_modem_create() name: P671A2VIVD010000, type: zte
ofonod[1632]: src/modem.c:set_modem_property() modem 0x87ca1b0 property Path
ofonod[1632]: src/modem.c:set_modem_property() modem 0x87ca1b0
property Registered
ofonod[1632]: plugins/udev.c:add_modem()
/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/ttyUSB0/tty/ttyUSB0
(zte)
ofonod[1632]: plugins/udev.c:add_zte() modem 0x87ca1b0
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property ModemRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property AuxRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0 property Path
ofonod[1632]: plugins/udev.c:add_modem()
/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.3/ttyUSB2/tty/ttyUSB2
(zte)
ofonod[1632]: plugins/udev.c:add_zte() modem 0x87ca1b0
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property ModemRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property AuxRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0 property Path
ofonod[1632]: plugins/udev.c:add_modem()
/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.1/ttyUSB1/tty/ttyUSB1
(zte)
ofonod[1632]: plugins/udev.c:add_zte() modem 0x87ca1b0
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property ModemRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property AuxRegistered
After that, if I run list-modems nothing happens.
I don't know if it is related, but I'm getting lots of error messages
from option driver:
option: option_instat_callback: error -2
They appear as soon as the modem is detected (after eject /dev/sr0).
Regards,
Thiago
6:51 a.m.
Hi Thiago,
>> I understand. I mixed up two problems and that got
confusing. The ZTE
>> modem is not showing the race condition issue. It didn't showed up
>> when I called list-modems. That is why I tested it with other
>> software, just to be sure it works with linux (MeeGo in this case). I
>> will test again with the ZTE modem and send the logs to the list.
>
> my ZTE modem works, but you need the latest oFono and its udev rules to
> make it detect.
I'm using ofono from git (last commit from yesterday) and the udev
rules are installed and loaded. The ZTE is a MF110.
When I plug the device, I need to call eject /dev/sr0, only after that
it is recognized correctly. After that, the following appears on ofono
log:
just install usb_modeswitch package and it will do this for you.
ofonod[1632]: src/modem.c:ofono_modem_create() name:
P671A2VIVD010000, type: zte
ofonod[1632]: src/modem.c:set_modem_property() modem 0x87ca1b0 property Path
ofonod[1632]: src/modem.c:set_modem_property() modem 0x87ca1b0
property Registered
ofonod[1632]: plugins/udev.c:add_modem()
/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/ttyUSB0/tty/ttyUSB0
(zte)
ofonod[1632]: plugins/udev.c:add_zte() modem 0x87ca1b0
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property ModemRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property AuxRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0 property Path
ofonod[1632]: plugins/udev.c:add_modem()
/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.3/ttyUSB2/tty/ttyUSB2
(zte)
ofonod[1632]: plugins/udev.c:add_zte() modem 0x87ca1b0
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property ModemRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property AuxRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0 property Path
ofonod[1632]: plugins/udev.c:add_modem()
/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.1/ttyUSB1/tty/ttyUSB1
(zte)
ofonod[1632]: plugins/udev.c:add_zte() modem 0x87ca1b0
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property ModemRegistered
ofonod[1632]: src/modem.c:get_modem_property() modem 0x87ca1b0
property AuxRegistered
After that, if I run list-modems nothing happens.
I don't know if it is related, but I'm getting lots of error messages
from option driver:
option: option_instat_callback: error -2
They appear as soon as the modem is detected (after eject /dev/sr0).
Sounds like a kernel bug. Which one are you using?
However show us your /proc/bus/usb/devices content for this modem.
Regards
Marcel
7:53 a.m.
> I don't know if it is related, but I'm getting lots of
error messages
> from option driver:
>
> option: option_instat_callback: error -2
>
> They appear as soon as the modem is detected (after eject /dev/sr0).
Sounds like a kernel bug. Which one are you using?
2.6.33.5
However show us your /proc/bus/usb/devices content for this modem.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=19d2 ProdID=0031 Rev= 0.00
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
From lsusb:
Bus 001 Device 006: ID 19d2:0031 ONDA Communication S.p.A.
Regards,
Thiago
4:21 p.m.
Hi Thiago,
>> I don't know if it is related, but I'm getting lots
of error messages
>> from option driver:
>>
>> option: option_instat_callback: error -2
>>
>> They appear as soon as the modem is detected (after eject /dev/sr0).
>
> Sounds like a kernel bug. Which one are you using?
2.6.33.5
> However show us your /proc/bus/usb/devices content for this modem.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=19d2 ProdID=0031 Rev= 0.00
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
From lsusb:
Bus 001 Device 006: ID 19d2:0031 ONDA Communication S.p.A.
so for sure the udev rule for your modem was missing. I added that one
now.
If the option driver is causing a problem, then I don't know. However I
am using a 2.6.33.6 F13 kernel without any problems.
Regards
Marcel
4404
days inactive
4415
days old
17 comments
3 participants
participants (3)
-
Denis Kenzior -
Marcel Holtmann -
Thiago Cangussu de Castro Gomes