-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Firmware loading times out #40
Comments
I believe I developed the retry method that you are talking about is
occurring, usually it happens due to the device not being ready to setup or
because there is an issue in the firmware but usually a retry or two does
the trick.
On Tue, Jul 28, 2020 at 11:22 AM bzfbd ***@***.***> wrote:
Sometimes firmware loading doesn't work on first try:
athp0: failed to receive control response completion, polling.. done 0
athp0: still no control response completion received, giving up.. done 0
athp0: ctl_resp never came in (-60, done 0)
athp0: failed to connect to HTC: -60
We can repeat this 1..n times (and I have seen really large n at one point
when this was happening for more than an hour).
It seems in those cases we cat three CE interrupts but no more.
I've seen pipe 0 and pipe 1 coming in in both orders but not convinced
myself that it is an actual race of some sort yet.
I have no insight into the firmware and wonder if that's something we have
more control over?
Also upstream with the new chipset support that entire interrupt 0 is FW
and things have been cleaned up and they only have 2 no longer 3 possible
setups dealing with. Do you think it might be worth porting just that logic
forward (also getting us closer to upstream)?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#40>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACAWBDIFXVMHG3CGA2GDCTR54CLRANCNFSM4PKXZC7Q>
.
--
Geramy L. Loveless
Founder & Chief Innovation Officer
JQluv.net, Inc.
Site: JQluv.com <http://www.jqluv.com/>
Mobile:
*559.999.1557*Office: *1 (877) 44 JQluv*
|
It'd be good to figure out why it's failing on the QCA6174, that's for
sure. Which other chips have problems loading firmware reliably?
Yes, we should eventually move closer to the upstream to include the CE
config changes.
…-adrian
|
In my case it's 988X Compex cards 600 and 900; I rarely see it on Intel (though it happens quite often according to my devlogs; I increased the timeouts for debugging and with that it's a lot more noticeable now). |
Yeah, please do experiment with the CE config path changes. :-) There's a
lot of weird crap that changed with which endpoint is used for what and
what their configs are..
…-a
|
Yeah, I agree, I also saw the same issue with the 900.
I have not played with the 600 though.
I have a new card i'll be testing. Maybe it's more related to firmware
issues or the startup and delay of the wireless device.
Perhaps we are hooking on the wrong event to initialize?
Or perhaps we are missing a hook to wait for, so we are initializing to
early?
Geramy L. Loveless
…On Tue, Jul 28, 2020 at 2:23 PM Adrian Chadd ***@***.***> wrote:
Yeah, please do experiment with the CE config path changes. :-) There's a
lot of weird crap that changed with which endpoint is used for what and
what their configs are..
-a
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#40 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACAWBHDIFTYXV6OAJBFB4LR54XV3ANCNFSM4PKXZC7Q>
.
|
There's fuckery with the CE config between ROMs, including CE5. It's trippy
and annoying.
…-adrian
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sometimes firmware loading doesn't work on first try:
athp0: failed to receive control response completion, polling.. done 0
athp0: still no control response completion received, giving up.. done 0
athp0: ctl_resp never came in (-60, done 0)
athp0: failed to connect to HTC: -60
We can repeat this 1..n times (and I have seen really large n at one point when this was happening for more than an hour).
It seems in those cases we cat three CE interrupts but no more.
I've seen pipe 0 and pipe 1 coming in in both orders but not convinced myself that it is an actual race of some sort yet.
I have no insight into the firmware and wonder if that's something we have more control over?
Also upstream with the new chipset support that entire interrupt 0 is FW and things have been cleaned up and they only have 2 no longer 3 possible setups dealing with. Do you think it might be worth porting just that logic forward (also getting us closer to upstream)?
The text was updated successfully, but these errors were encountered: