It dies with 'otp calibration failed: 2'.
Some older version of the driver seemed to work fine.
--Andy
On Thu, May 29, 2014 at 12:48 AM, Michal Kazior <[email protected]> wrote:
> [email protected]
>
> On 28 May 2014 20:35, Andy Lutomirski <[email protected]> wrote:
>> It dies with 'otp calibration failed: 2'.
>>
>> Some older version of the driver seemed to work fine.
>
> ath10k did not verify otp result before so it could load successfully
> despite errors.
>
> Someone raised this problem yesterday on IRC. I'm not really sure how
> we should deal with this properly.
>
Ideally, someone from Atheros could figure out what the error is.
Barring that, the card seems to work okay without otp (I don't even
know what otp is), so just warning and continuing to load might be
better than bailing.
--Andy
[email protected]
On 28 May 2014 20:35, Andy Lutomirski <[email protected]> wrote:
> It dies with 'otp calibration failed: 2'.
>
> Some older version of the driver seemed to work fine.
ath10k did not verify otp result before so it could load successfully
despite errors.
Someone raised this problem yesterday on IRC. I'm not really sure how
we should deal with this properly.
Michał
On 06/05/2014 11:39 PM, Kalle Valo wrote:
> Ben Greear <[email protected]> writes:
>
>>> Michal already did. The error means that for some reason the
>>> calibaration data was not found from OTP. OTP is the storage area where
>>> the calibration data is normally stored within QCA9880.
>>
>> I fought this with .387 firmware and WLE900VX NICs. If it's a common
>> problem with more than a single NIC (ie, not just a bad piece of
>> hardware), then one could load my firmware and my ath10k patches.
>
> That's XB143, right? I think that's different as firmware started to
> support XB143 only starting from 10.1.467.
Yes. My point is that I have the ability to get debug info out of
of the otp in my modified firmware, so it is possible to debug why
the otp is failing in the first place, and possibly fix otp to work
with that NIC.
I'll start begging to get my CT firmware support in upstream kernels
as soon as we get the firmware-crash stuff ironed out :)
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Thu, Jun 5, 2014 at 9:08 AM, Ben Greear <[email protected]> wrote:
> On 06/05/2014 03:26 AM, Kalle Valo wrote:
>> Andy Lutomirski <[email protected]> writes:
>>
>>> On Thu, May 29, 2014 at 12:48 AM, Michal Kazior <[email protected]> wrote:
>>>> [email protected]
>>>>
>>>> On 28 May 2014 20:35, Andy Lutomirski <[email protected]> wrote:
>>>>> It dies with 'otp calibration failed: 2'.
>>>>>
>>>>> Some older version of the driver seemed to work fine.
>>>>
>>>> ath10k did not verify otp result before so it could load successfully
>>>> despite errors.
>>>>
>>>> Someone raised this problem yesterday on IRC. I'm not really sure how
>>>> we should deal with this properly.
>>>
>>> Ideally, someone from Atheros could figure out what the error is.
>>
>> Michal already did. The error means that for some reason the
>> calibaration data was not found from OTP. OTP is the storage area where
>> the calibration data is normally stored within QCA9880.
>
> I fought this with .387 firmware and WLE900VX NICs. If it's a common
> problem with more than a single NIC (ie, not just a bad piece of
> hardware), then one could load my firmware and my ath10k patches.
No clue. I can buy another one of these things to find out, though,
if that would help.
>
> I have a way to effectively get text debug messages out of the
> OTP firmware code and can probably debug this (eventually...busy
> with other things currently).
Is this something you can send me? If not, and if you have time, I'd
be happy to mail you your very own Archer C7 v2.
OTOH, if this is likely to be it, then it might be a decent thing to play with:
http://web.mit.edu/luto/www/archerc7_gpl/atheros/otp.c
This hardware has two Atheros WLANs: a platform device ath9k and a
minipcie ath10k. Would ath9k also have something called 'OTP'?
>
> If you know the basic hardware architecture of the NIC, then you can at least
> make a better guess of the calibration data and choose an eeprom
> table that is a better match than just total failure of OTP.
>
I don't even know what that means. :(
>>> Barring that, the card seems to work okay without otp (I don't even
>>> know what otp is), so just warning and continuing to load might be
>>> better than bailing.
>>
>> This means that your card is not properly calibrated and it doesn't
>> function in an optimal way (for example range or throughput is less than
>> what it could be).
>
> And, your MAC address will be wrong and identical to all other devices of this
> type, which means the second one of these NICs
> on your network will make everything go to hell.
>
Heh. I'm already overriding the MAC address with a locally administered one.
> Thanks,
> Ben
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
--
Andy Lutomirski
AMA Capital Management, LLC
On Thu, Jun 5, 2014 at 3:26 AM, Kalle Valo <[email protected]> wrote:
> Andy Lutomirski <[email protected]> writes:
>
>> On Thu, May 29, 2014 at 12:48 AM, Michal Kazior <[email protected]> wrote:
>>> [email protected]
>>>
>>> On 28 May 2014 20:35, Andy Lutomirski <[email protected]> wrote:
>>>> It dies with 'otp calibration failed: 2'.
>>>>
>>>> Some older version of the driver seemed to work fine.
>>>
>>> ath10k did not verify otp result before so it could load successfully
>>> despite errors.
>>>
>>> Someone raised this problem yesterday on IRC. I'm not really sure how
>>> we should deal with this properly.
>>
>> Ideally, someone from Atheros could figure out what the error is.
>
> Michal already did. The error means that for some reason the
> calibaration data was not found from OTP. OTP is the storage area where
> the calibration data is normally stored within QCA9880.
Ah -- I misunderstood. I assumed that the OTP read was failing
mysteriously and that expert input was needed to resolve that mystery
:)
>
>> Barring that, the card seems to work okay without otp (I don't even
>> know what otp is), so just warning and continuing to load might be
>> better than bailing.
>
> This means that your card is not properly calibrated and it doesn't
> function in an optimal way (for example range or throughput is less than
> what it could be).
>
> Do you see that with all Archer C7 v2 devices or with just one? One
> possibility is that the calibration data is actually stored outside of
> QCA9880 board, for example in the host flash or similar. I don't have
> that AP, can someone else see where the calibration data is stored?
I only have one of these. I put a likely looking directory of the GPL
sources here:
http://web.mit.edu/luto/www/archerc7_gpl/atheros/
I'm not entirely sure what I'm looking for, but this might be it:
http://web.mit.edu/luto/www/archerc7_gpl/atheros/otp.c
I don't really know what I'm looking for, though.
--Andy
On 06/05/2014 03:26 AM, Kalle Valo wrote:
> Andy Lutomirski <[email protected]> writes:
>
>> On Thu, May 29, 2014 at 12:48 AM, Michal Kazior <[email protected]> wrote:
>>> [email protected]
>>>
>>> On 28 May 2014 20:35, Andy Lutomirski <[email protected]> wrote:
>>>> It dies with 'otp calibration failed: 2'.
>>>>
>>>> Some older version of the driver seemed to work fine.
>>>
>>> ath10k did not verify otp result before so it could load successfully
>>> despite errors.
>>>
>>> Someone raised this problem yesterday on IRC. I'm not really sure how
>>> we should deal with this properly.
>>
>> Ideally, someone from Atheros could figure out what the error is.
>
> Michal already did. The error means that for some reason the
> calibaration data was not found from OTP. OTP is the storage area where
> the calibration data is normally stored within QCA9880.
I fought this with .387 firmware and WLE900VX NICs. If it's a common
problem with more than a single NIC (ie, not just a bad piece of
hardware), then one could load my firmware and my ath10k patches.
I have a way to effectively get text debug messages out of the
OTP firmware code and can probably debug this (eventually...busy
with other things currently).
If you know the basic hardware architecture of the NIC, then you can at least
make a better guess of the calibration data and choose an eeprom
table that is a better match than just total failure of OTP.
>> Barring that, the card seems to work okay without otp (I don't even
>> know what otp is), so just warning and continuing to load might be
>> better than bailing.
>
> This means that your card is not properly calibrated and it doesn't
> function in an optimal way (for example range or throughput is less than
> what it could be).
And, your MAC address will be wrong and identical to all other devices of this
type, which means the second one of these NICs
on your network will make everything go to hell.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Andy Lutomirski <[email protected]> writes:
> On Thu, May 29, 2014 at 12:48 AM, Michal Kazior <[email protected]> wrote:
>> [email protected]
>>
>> On 28 May 2014 20:35, Andy Lutomirski <[email protected]> wrote:
>>> It dies with 'otp calibration failed: 2'.
>>>
>>> Some older version of the driver seemed to work fine.
>>
>> ath10k did not verify otp result before so it could load successfully
>> despite errors.
>>
>> Someone raised this problem yesterday on IRC. I'm not really sure how
>> we should deal with this properly.
>
> Ideally, someone from Atheros could figure out what the error is.
Michal already did. The error means that for some reason the
calibaration data was not found from OTP. OTP is the storage area where
the calibration data is normally stored within QCA9880.
> Barring that, the card seems to work okay without otp (I don't even
> know what otp is), so just warning and continuing to load might be
> better than bailing.
This means that your card is not properly calibrated and it doesn't
function in an optimal way (for example range or throughput is less than
what it could be).
Do you see that with all Archer C7 v2 devices or with just one? One
possibility is that the calibration data is actually stored outside of
QCA9880 board, for example in the host flash or similar. I don't have
that AP, can someone else see where the calibration data is stored?
I know that ath9k supports this kind of setup, most likely ath10k should
as well.
--
Kalle Valo
Ben Greear <[email protected]> writes:
>> Michal already did. The error means that for some reason the
>> calibaration data was not found from OTP. OTP is the storage area where
>> the calibration data is normally stored within QCA9880.
>
> I fought this with .387 firmware and WLE900VX NICs. If it's a common
> problem with more than a single NIC (ie, not just a bad piece of
> hardware), then one could load my firmware and my ath10k patches.
That's XB143, right? I think that's different as firmware started to
support XB143 only starting from 10.1.467.
--
Kalle Valo