carl9170 firmware

carl9170 firmware

[Larry Finger]

Christian,

A question regarding adding carl9170-1.fw to the openSUSE firmware package is 
being discussed on the oS kernel mailing list; however, I do not see that one in 
the linux-firmware git repo. Should it be there? Is there a legal problem with 
redistribution?

Thanks,

Larry

Re: carl9170 firmware

[Christian Lamparter]

On Tuesday, April 17, 2012 07:25:25 PM Larry Finger wrote:
> Christian,
> 
> A question regarding adding carl9170-1.fw to the openSUSE firmware package is 
> being discussed on the oS kernel mailing list; however, I do not see that one
> in the linux-firmware git repo. Should it be there? 
Does the repo take source code releases? [much like the work we do for the
kernel driver, or have you ever seen a binary release on this ML :D ]. The
files on <http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware_binary>
are just for convenience.
 
> Is there a legal problem with redistribution?
Not that I know of.

Regards,
	Christian

Re: carl9170 firmware

[Larry Finger]

On 04/17/2012 01:35 PM, Christian Lamparter wrote:
> On Tuesday, April 17, 2012 07:25:25 PM Larry Finger wrote:
>> Christian,
>>
>> A question regarding adding carl9170-1.fw to the openSUSE firmware package is
>> being discussed on the oS kernel mailing list; however, I do not see that one
>> in the linux-firmware git repo. Should it be there?
> Does the repo take source code releases? [much like the work we do for the
> kernel driver, or have you ever seen a binary release on this ML :D ]. The
> files on<http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware_binary>
> are just for convenience.

AFAIK, the repo only takes binary files. With the source under GPL2, that should 
not be a problem; however, the fact that there are two versions with the same 
name would be trouble. Adding under that name has the possibility of breaking 
all the systems that use the other version.

Too bad that the newer firmware was not renamed carl9170-2.fw. Then both could 
be added to the repo and the driver could load whichever one it needed. 
Unfortunately, making that change now would be difficult to propagate back to 
all the stable versions, but you might consider it for V3.5 and forward. In 
conjunction with that change, submit the newer firmware to the firmware repo 
with the -2 name. That won't break anyone's system. Users for kernels up to 3.4 
will still see what they did before.

>> Is there a legal problem with redistribution?
> Not that I know of.

With a GPLv2 license, there will be no problem.

Larry


> Regards,
> 	Christian
>

Re: carl9170 firmware

[Christian Lamparter]

On Tuesday, April 17, 2012 09:27:53 PM Larry Finger wrote:
> On 04/17/2012 01:35 PM, Christian Lamparter wrote:
> > On Tuesday, April 17, 2012 07:25:25 PM Larry Finger wrote:
> >> A question regarding adding carl9170-1.fw to the openSUSE firmware package is
> >> being discussed on the oS kernel mailing list; however, I do not see that one
> >> in the linux-firmware git repo. Should it be there?
> > Does the repo take source code releases? [much like the work we do for the
> > kernel driver, or have you ever seen a binary release on this ML :D ]. The
> > files on<http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware_binary>
> > are just for convenience.
> 
> AFAIK, the repo only takes binary files. With the source under GPL2, that should 
> not be a problem; however, the fact that there are two versions with the same 
> name would be trouble. Adding under that name has the possibility of breaking 
> all the systems that use the other version.
I think I would need to read the opensuse ML discussion first to know why this
is a "big" deal suddenly. (do you have a link?)

On the other hand: I don't like the idea of supporting "old" & "new" firmwares.
Usually they get mixed up and then you end up with "new" reports for
"old" bugs. In fact, p54 users' complain about that alot.

Regards,
	Chr

Re: carl9170 firmware

[Larry Finger]

On 04/18/2012 01:26 PM, Christian Lamparter wrote:
> On Tuesday, April 17, 2012 09:27:53 PM Larry Finger wrote:
>> On 04/17/2012 01:35 PM, Christian Lamparter wrote:
>>> On Tuesday, April 17, 2012 07:25:25 PM Larry Finger wrote:
>>>> A question regarding adding carl9170-1.fw to the openSUSE firmware package is
>>>> being discussed on the oS kernel mailing list; however, I do not see that one
>>>> in the linux-firmware git repo. Should it be there?
>>> Does the repo take source code releases? [much like the work we do for the
>>> kernel driver, or have you ever seen a binary release on this ML :D ]. The
>>> files on<http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware_binary>
>>> are just for convenience.
>>
>> AFAIK, the repo only takes binary files. With the source under GPL2, that should
>> not be a problem; however, the fact that there are two versions with the same
>> name would be trouble. Adding under that name has the possibility of breaking
>> all the systems that use the other version.
> I think I would need to read the opensuse ML discussion first to know why this
> is a "big" deal suddenly. (do you have a link?)
>
> On the other hand: I don't like the idea of supporting "old"&  "new" firmwares.
> Usually they get mixed up and then you end up with "new" reports for
> "old" bugs. In fact, p54 users' complain about that alot.

If the filename that the driver requests is changed, that should reduce the 
complaints. I would think that the current setup with two different, 
incompatible versions having the same name would be trouble.

The thread is at http://lists.opensuse.org/opensuse-kernel/2012-04/msg00040.html.

Larry

Re: Carl9170 Firmware

[Christian Lamparter]

On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
> While using the past days the carl9170 firmware with a USB card under a
> linux guest running different kernel and driver versions I kept running into
> the issue of a usb disconnect when the card was put under load:
linux guest? You are not using carl9170 in a VM, are you?

>  usb 1-1: no command feedback received (-110).
>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
>  usb 1-1: restart device (6)
> 
> No matter what kernel driver/firmware I tried I will still get it. I decided
> to look into it a bit more and I narrowed it down to be a firmware issue
> with the following code snippet:
Or it could be a problem with the USB PHY. However, the driver
seems to be able to handle the situation and restarts the device
accordingly.
 
> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
> 
>         case CARL9170_CMD_WREG:
> esp->hdr.len = 0;
>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
>                 break;
> 
> That code appears to handle event 1 which is a write into a register. In
> some cases that write appeared to cause a failure and a reset into the card.
> I added a simple delay loop before the switch statement and that seemed to
> fix the issue and I don't lose the card anymore even under a lot of load.
> Obviously that's not a real fix and something else more reliable needs to be
> in place.
Any idea what this "something" else might be?

Regards,
	Chr

Re: Carl9170 Firmware

[J Igrap]

Hi Chr,

On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
>> While using the past days the carl9170 firmware with a USB card under a
>> linux guest running different kernel and driver versions I kept running into
>> the issue of a usb disconnect when the card was put under load:
> linux guest? You are not using carl9170 in a VM, are you?
>

It is in a VM. I was working on a VM for ease of debugging the issue.

>>  usb 1-1: no command feedback received (-110).
>>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
>>  usb 1-1: restart device (6)
>>
>> No matter what kernel driver/firmware I tried I will still get it. I decided
>> to look into it a bit more and I narrowed it down to be a firmware issue
>> with the following code snippet:
> Or it could be a problem with the USB PHY. However, the driver
> seems to be able to handle the situation and restarts the device
> accordingly.
>

I tried with several physical devices and they all seemed to have the
same behavior.
The device does restart however you lose connectivity and state of
what you were doing.


>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
>>
>>         case CARL9170_CMD_WREG:
>> esp->hdr.len = 0;
>>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
>>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
>>                 break;
>>
>> That code appears to handle event 1 which is a write into a register. In
>> some cases that write appeared to cause a failure and a reset into the card.
>> I added a simple delay loop before the switch statement and that seemed to
>> fix the issue and I don't lose the card anymore even under a lot of load.
>> Obviously that's not a real fix and something else more reliable needs to be
>> in place.
> Any idea what this "something" else might be?
>

I'm not very familiar with how USB works, maybe someone with more
experience can shed some light here? It seems to me that the event
handling needs to be slowed down a little or add some kind of
verification.

Best,
Jigrap

> Regards,
>        Chr
>

Re: Carl9170 Firmware

[Christian Lamparter]

On Wednesday, September 14, 2011 03:09:14 PM J Igrap wrote:
> On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter
>> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
>>> While using the past days the carl9170 firmware with a USB card under a
>>> linux guest running different kernel and driver versions I kept running into
>>> the issue of a usb disconnect when the card was put under load:
>> linux guest? You are not using carl9170 in a VM, are you?
>>
> It is in a VM. I was working on a VM for ease of debugging the issue.
So, I presume you have already tried running the driver natively
and it fails in a similar fashion, right? [I just want to rule out
a bug in the VM layers]

>>>  usb 1-1: no command feedback received (-110).
>>>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
>>>  usb 1-1: restart device (6)
>>>
>>> No matter what kernel driver/firmware I tried I will still get it. I decided
>>> to look into it a bit more and I narrowed it down to be a firmware issue
>>> with the following code snippet:
>> Or it could be a problem with the USB PHY. However, the driver
>> seems to be able to handle the situation and restarts the device
>> accordingly.
>> 
> I tried with several physical devices and they all seemed to have the
> same behavior. The device does restart however you lose connectivity
> and state of what you were doing.
Any transmission protocol should be able to handle loss of connectivity.
Furthermore all connection managers [wpa_supplicant, NetworkManager, wicd]
will automatically reestablish the link if the device was put out by a
catastrophic failure.

>>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
>>>
>>>         case CARL9170_CMD_WREG:
>>> esp->hdr.len = 0;
>>>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
>>>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
>>>                 break;
>>>
>>> That code appears to handle event 1 which is a write into a register. In
>>> some cases that write appeared to cause a failure and a reset into the card.
>>> I added a simple delay loop before the switch statement and that seemed to
>>> fix the issue and I don't lose the card anymore even under a lot of load.
>>> Obviously that's not a real fix and something else more reliable needs to be
>>> in place.
>> Any idea what this "something" else might be?
> 
> I'm not very familiar with how USB works, maybe someone with more
> experience can shed some light here? It seems to me that the event
> handling needs to be slowed down a little or add some kind of
> verification.
the usb protocol already incorporates some verification
http://www.beyondlogic.org/usbnutshell/usb3.shtml

furthermore, the driver counts each command frame, therefore it can
detect whenever a frame was lost.

Regards,
	Chr

Re: Carl9170 Firmware

[J Igrap]

On Wed, Sep 14, 2011 at 1:00 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Wednesday, September 14, 2011 03:09:14 PM J Igrap wrote:
>> On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter
>>> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
>>>> While using the past days the carl9170 firmware with a USB card under a
>>>> linux guest running different kernel and driver versions I kept running into
>>>> the issue of a usb disconnect when the card was put under load:
>>> linux guest? You are not using carl9170 in a VM, are you?
>>>
>> It is in a VM. I was working on a VM for ease of debugging the issue.
> So, I presume you have already tried running the driver natively
> and it fails in a similar fashion, right? [I just want to rule out
> a bug in the VM layers]
>

Yes, it appears to fail in slow/older physicals too.


>>>>  usb 1-1: no command feedback received (-110).
>>>>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
>>>>  usb 1-1: restart device (6)
>>>>
>>>> No matter what kernel driver/firmware I tried I will still get it. I decided
>>>> to look into it a bit more and I narrowed it down to be a firmware issue
>>>> with the following code snippet:
>>> Or it could be a problem with the USB PHY. However, the driver
>>> seems to be able to handle the situation and restarts the device
>>> accordingly.
>>>
>> I tried with several physical devices and they all seemed to have the
>> same behavior. The device does restart however you lose connectivity
>> and state of what you were doing.
> Any transmission protocol should be able to handle loss of connectivity.
> Furthermore all connection managers [wpa_supplicant, NetworkManager, wicd]
> will automatically reestablish the link if the device was put out by a
> catastrophic failure.
>
>>>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
>>>>
>>>>         case CARL9170_CMD_WREG:
>>>> esp->hdr.len = 0;
>>>>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
>>>>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
>>>>                 break;
>>>>
>>>> That code appears to handle event 1 which is a write into a register. In
>>>> some cases that write appeared to cause a failure and a reset into the card.
>>>> I added a simple delay loop before the switch statement and that seemed to
>>>> fix the issue and I don't lose the card anymore even under a lot of load.
>>>> Obviously that's not a real fix and something else more reliable needs to be
>>>> in place.
>>> Any idea what this "something" else might be?
>>
>> I'm not very familiar with how USB works, maybe someone with more
>> experience can shed some light here? It seems to me that the event
>> handling needs to be slowed down a little or add some kind of
>> verification.
> the usb protocol already incorporates some verification
> http://www.beyondlogic.org/usbnutshell/usb3.shtml
>
> furthermore, the driver counts each command frame, therefore it can
> detect whenever a frame was lost.


It does detect it and restarts the device, however when running under
VMware or slower physicals it gets in the way since the device resets
very often.
I tried build various firmware's as an experiment and I noticed that
the higher I set the Max Frame Length the more resistant it becomes.
The script I wrote basically sends
a beacon packet multiple times in monitor mode and has a counter of
how many packets went through before the card resets. Any ideas what
could be causing this?




>
> Regards,
>        Chr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


On Wed, Sep 14, 2011 at 1:00 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Wednesday, September 14, 2011 03:09:14 PM J Igrap wrote:
>> On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter
>>> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
>>>> While using the past days the carl9170 firmware with a USB card under a
>>>> linux guest running different kernel and driver versions I kept running into
>>>> the issue of a usb disconnect when the card was put under load:
>>> linux guest? You are not using carl9170 in a VM, are you?
>>>
>> It is in a VM. I was working on a VM for ease of debugging the issue.
> So, I presume you have already tried running the driver natively
> and it fails in a similar fashion, right? [I just want to rule out
> a bug in the VM layers]
>
>>>>  usb 1-1: no command feedback received (-110).
>>>>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
>>>>  usb 1-1: restart device (6)
>>>>
>>>> No matter what kernel driver/firmware I tried I will still get it. I decided
>>>> to look into it a bit more and I narrowed it down to be a firmware issue
>>>> with the following code snippet:
>>> Or it could be a problem with the USB PHY. However, the driver
>>> seems to be able to handle the situation and restarts the device
>>> accordingly.
>>>
>> I tried with several physical devices and they all seemed to have the
>> same behavior. The device does restart however you lose connectivity
>> and state of what you were doing.
> Any transmission protocol should be able to handle loss of connectivity.
> Furthermore all connection managers [wpa_supplicant, NetworkManager, wicd]
> will automatically reestablish the link if the device was put out by a
> catastrophic failure.
>
>>>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
>>>>
>>>>         case CARL9170_CMD_WREG:
>>>> esp->hdr.len = 0;
>>>>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
>>>>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
>>>>                 break;
>>>>
>>>> That code appears to handle event 1 which is a write into a register. In
>>>> some cases that write appeared to cause a failure and a reset into the card.
>>>> I added a simple delay loop before the switch statement and that seemed to
>>>> fix the issue and I don't lose the card anymore even under a lot of load.
>>>> Obviously that's not a real fix and something else more reliable needs to be
>>>> in place.
>>> Any idea what this "something" else might be?
>>
>> I'm not very familiar with how USB works, maybe someone with more
>> experience can shed some light here? It seems to me that the event
>> handling needs to be slowed down a little or add some kind of
>> verification.
> the usb protocol already incorporates some verification
> http://www.beyondlogic.org/usbnutshell/usb3.shtml
>
> furthermore, the driver counts each command frame, therefore it can
> detect whenever a frame was lost.
>
> Regards,
>        Chr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Carl9170 Firmware

[Christian Lamparter]

On Wednesday, April 11, 2012 03:20:24 PM J Igrap wrote:
> On Wed, Sep 14, 2011 at 1:00 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Wednesday, September 14, 2011 03:09:14 PM J Igrap wrote:
> >> On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter
> >>> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
> >>>> While using the past days the carl9170 firmware with a USB card under a
> >>>> linux guest running different kernel and driver versions I kept running into
> >>>> the issue of a usb disconnect when the card was put under load:
> >>> linux guest? You are not using carl9170 in a VM, are you?
> >>>
> >> It is in a VM. I was working on a VM for ease of debugging the issue.
> > So, I presume you have already tried running the driver natively
> > and it fails in a similar fashion, right? [I just want to rule out
> > a bug in the VM layers]
> >
> 
> Yes, it appears to fail in slow/older physicals too.

what's "slower/older"? I know a few people reported problems with embedded USB
HCDs but that's understandable. However, I occasionally test carl9170 on a 7
year old laptop and so far it runs ok.
 
> >>>>  usb 1-1: no command feedback received (-110).
> >>>>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
> >>>>  usb 1-1: restart device (6)
> >>>>
> >>>> No matter what kernel driver/firmware I tried I will still get it. I decided
> >>>> to look into it a bit more and I narrowed it down to be a firmware issue
> >>>> with the following code snippet:
> >>> Or it could be a problem with the USB PHY. However, the driver
> >>> seems to be able to handle the situation and restarts the device
> >>> accordingly.
> >>>
> >> I tried with several physical devices and they all seemed to have the
> >> same behavior. The device does restart however you lose connectivity
> >> and state of what you were doing.
> > Any transmission protocol should be able to handle loss of connectivity.
> > Furthermore all connection managers [wpa_supplicant, NetworkManager, wicd]
> > will automatically reestablish the link if the device was put out by a
> > catastrophic failure.
> >
> >>>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
> >>>>
> >>>>         case CARL9170_CMD_WREG:
> >>>> esp->hdr.len = 0;
> >>>>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
> >>>>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
> >>>>                 break;
> >>>>
> >>>> That code appears to handle event 1 which is a write into a register. In
> >>>> some cases that write appeared to cause a failure and a reset into the card.
> >>>> I added a simple delay loop before the switch statement and that seemed to
> >>>> fix the issue and I don't lose the card anymore even under a lot of load.
> >>>> Obviously that's not a real fix and something else more reliable needs to be
> >>>> in place.
> >>> Any idea what this "something" else might be?
> >>
> >> I'm not very familiar with how USB works, maybe someone with more
> >> experience can shed some light here? It seems to me that the event
> >> handling needs to be slowed down a little or add some kind of
> >> verification.
> > the usb protocol already incorporates some verification
> > http://www.beyondlogic.org/usbnutshell/usb3.shtml
> >
> > furthermore, the driver counts each command frame, therefore it can
> > detect whenever a frame was lost.
> 
> It does detect it and restarwts the device, hoever when running under
> VMware os r slower physicalit gets in the way since the device resets
> very often.
>
> I tried build various firmware's as an experiment and I noticed that
> the higher I set the Max Frame Length the more resistant it becomes.
> The script I wrote basically sends
> a beacon packet multiple times in monitor mode and has a counter of
> how many packets went through before the card resets. Any ideas what
> could be causing this?
no. Unlike ath9k_htc fw, carl9170 does not have "space" to add any
sophisticated tracer. So, you are stuck with the 1/2-bit LEDs as a
window to the device.

Regards,
	Christian

Re: Carl9170 Firmware

[J Igrap]

On Wed, Apr 11, 2012 at 12:54 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Wednesday, April 11, 2012 03:20:24 PM J Igrap wrote:
>> On Wed, Sep 14, 2011 at 1:00 PM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On Wednesday, September 14, 2011 03:09:14 PM J Igrap wrote:
>> >> On Wed, Sep 14, 2011 at 5:50 AM, Christian Lamparter
>> >>> On Tuesday, September 13, 2011 11:18:23 PM J Igrap wrote:
>> >>>> While using the past days the carl9170 firmware with a USB card under a
>> >>>> linux guest running different kernel and driver versions I kept running into
>> >>>> the issue of a usb disconnect when the card was put under load:
>> >>> linux guest? You are not using carl9170 in a VM, are you?
>> >>>
>> >> It is in a VM. I was working on a VM for ease of debugging the issue.
>> > So, I presume you have already tried running the driver natively
>> > and it fails in a similar fashion, right? [I just want to rule out
>> > a bug in the VM layers]
>> >
>>
>> Yes, it appears to fail in slow/older physicals too.
>
> what's "slower/older"? I know a few people reported problems with embedded USB
> HCDs but that's understandable. However, I occasionally test carl9170 on a 7
> year old laptop and so far it runs ok.
>

A physical pentium 4 single core machine. Also pretty much every
vmware version (workstation and fusion).
The card gets reset randomly.


>> >>>>  usb 1-1: no command feedback received (-110).
>> >>>>  carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
>> >>>>  usb 1-1: restart device (6)
>> >>>>
>> >>>> No matter what kernel driver/firmware I tried I will still get it. I decided
>> >>>> to look into it a bit more and I narrowed it down to be a firmware issue
>> >>>> with the following code snippet:
>> >>> Or it could be a problem with the USB PHY. However, the driver
>> >>> seems to be able to handle the situation and restarts the device
>> >>> accordingly.
>> >>>
>> >> I tried with several physical devices and they all seemed to have the
>> >> same behavior. The device does restart however you lose connectivity
>> >> and state of what you were doing.
>> > Any transmission protocol should be able to handle loss of connectivity.
>> > Furthermore all connection managers [wpa_supplicant, NetworkManager, wicd]
>> > will automatically reestablish the link if the device was put out by a
>> > catastrophic failure.
>> >
>> >>>> void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
>> >>>>
>> >>>>         case CARL9170_CMD_WREG:
>> >>>> esp->hdr.len = 0;
>> >>>>                 for (i = 0; i < (cmd->hdr.len / 8); i++)
>> >>>>                         set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
>> >>>>                 break;
>> >>>>
>> >>>> That code appears to handle event 1 which is a write into a register. In
>> >>>> some cases that write appeared to cause a failure and a reset into the card.
>> >>>> I added a simple delay loop before the switch statement and that seemed to
>> >>>> fix the issue and I don't lose the card anymore even under a lot of load.
>> >>>> Obviously that's not a real fix and something else more reliable needs to be
>> >>>> in place.
>> >>> Any idea what this "something" else might be?
>> >>
>> >> I'm not very familiar with how USB works, maybe someone with more
>> >> experience can shed some light here? It seems to me that the event
>> >> handling needs to be slowed down a little or add some kind of
>> >> verification.
>> > the usb protocol already incorporates some verification
>> > http://www.beyondlogic.org/usbnutshell/usb3.shtml
>> >
>> > furthermore, the driver counts each command frame, therefore it can
>> > detect whenever a frame was lost.
>>
>> It does detect it and restarwts the device, hoever when running under
>> VMware os r slower physicalit gets in the way since the device resets
>> very often.
>>
>> I tried build various firmware's as an experiment and I noticed that
>> the higher I set the Max Frame Length the more resistant it becomes.
>> The script I wrote basically sends
>> a beacon packet multiple times in monitor mode and has a counter of
>> how many packets went through before the card resets. Any ideas what
>> could be causing this?
> no. Unlike ath9k_htc fw, carl9170 does not have "space" to add any
> sophisticated tracer. So, you are stuck with the 1/2-bit LEDs as a
> window to the device.
>
> Regards,
>        Christian

Carl9170 firmware

[J Igrap]

While using the past days the carl9170 firmware with a USB card under
a linux guest running different kernel and driver versions I kept
running into the issue of a usb disconnect when the card was put under
load:
 usb 1-1: no command feedback received (-110).
 carl9170 cmd: 08 01 00 00 f0 36 1c 00 00 24 00 00              .....6...$..
 usb 1-1: restart device (6)

No matter what kernel driver/firmware I tried I will still get it. I
decided to look into it a bit more and I narrowed it down to be a
firmware issue with the following code snippet:

void handle_cmd(struct carl9170_rsp *resp) in src/cmd.c
        case CARL9170_CMD_WREG:
esp->hdr.len = 0;
                for (i = 0; i < (cmd->hdr.len / 8); i++)
                        set(cmd->wreg.regs[i].addr, cmd->wreg.regs[i].val);
                break;

That code appears to handle event 1 which is a write into a register.
In some cases that write appeared to cause a failure and a reset into
the card. I added a simple delay loop before the switch statement and
that seemed to fix the issue and I don't lose the card anymore even
under a lot of load. Obviously that's not a real fix and something
else more reliable needs to be in place.

-jigrap