Message ID | 564E130D.4080201@dd-wrt.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Sebastian Gottschall <s.gottschall@dd-wrt.com> writes: > simple solution. > > as for ath9k. otp must be ignored for various chipsets, since they > wont return valid results > > --- core.c (Revision 2702) > +++ core.c (Arbeitskopie) > @@ -1735,9 +1735,8 @@ > > ret = ath10k_core_get_board_id_from_otp(ar); > if (ret && ret != -EOPNOTSUPP) { > - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", > + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, > ignore\n", > ret); > - return ret; > } > > ret = ath10k_core_fetch_board_file(ar); I'm guessing in your case otp.bin crashes as the calibration data is in flash (and not in otp). Can you send dmesg from a successful ath10k boot so that I can verify ath10k reads the calibration data from a file? I think I have an idea how to cleanly fix this.
the patch subjected with: ath10k: use pre-allocated DMA buffer in Tx must be reverted. it will lead to out of memory when using multiple cards on ipq806x. it seems that there isnt enough dma buffer available on this platform reverting this patch will fix it Am 20.11.2015 um 12:53 schrieb Kalle Valo: > Sebastian Gottschall <s.gottschall@dd-wrt.com> writes: > >> simple solution. >> >> as for ath9k. otp must be ignored for various chipsets, since they >> wont return valid results >> >> --- core.c (Revision 2702) >> +++ core.c (Arbeitskopie) >> @@ -1735,9 +1735,8 @@ >> >> ret = ath10k_core_get_board_id_from_otp(ar); >> if (ret && ret != -EOPNOTSUPP) { >> - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", >> + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, >> ignore\n", >> ret); >> - return ret; >> } >> >> ret = ath10k_core_fetch_board_file(ar); > I'm guessing in your case otp.bin crashes as the calibration data is in > flash (and not in otp). Can you send dmesg from a successful ath10k boot > so that I can verify ath10k reads the calibration data from a file? > > I think I have an idea how to cleanly fix this. >
On 11/20/2015 07:55 AM, Sebastian Gottschall wrote: > > the patch subjected with: ath10k: use pre-allocated DMA buffer in Tx > must be reverted. > it will lead to out of memory when using multiple cards on ipq806x. it seems that there isnt enough dma buffer available on this platform > reverting this patch will fix it Maybe it can be re-implemented so that it uses the old behaviour if the allocation fails. That way, we can still get performance improvement on systems that have the DMA buffer space available? Thanks, Ben
On 11/19/2015 10:21 AM, Sebastian Gottschall wrote: > simple solution. > > as for ath9k. otp must be ignored for various chipsets, since they wont return valid results > > --- core.c (Revision 2702) > +++ core.c (Arbeitskopie) > @@ -1735,9 +1735,8 @@ > > ret = ath10k_core_get_board_id_from_otp(ar); > if (ret && ret != -EOPNOTSUPP) { > - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", > + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, ignore\n", > ret); > - return ret; > } > > ret = ath10k_core_fetch_board_file(ar); I received a report of the same problem reported below from someone using an i7 processor on some random motherboard. Same NIC, kernel, and firmware works fine on my systems, so it appears to be platform dependent somehow. Did you find a better solution other than just ignoring the OTP failure? Thanks, Ben > > > > Am 19.11.2015 um 18:12 schrieb Sebastian Gottschall: >> Am 19.11.2015 um 17:13 schrieb Ben Greear: >>> >>> git clone git://dmz2.candelatech.com/linux.ath >> same effect with yours >> >> 6.201141] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142) >> [ 6.201593] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0 >> [ 8.578573] ath10k_pci 0000:01:00.0: unable to read from the device >> [ 8.578605] ath10k_pci 0000:01:00.0: could not execute otp for board id check: -110 >> [ 8.583648] ath10k_pci 0000:01:00.0: failed to get board id from otp for qca99x0: -110 >> [ 8.591338] ath10k_pci 0000:01:00.0: could not probe fw (-110) >> [ 8.600062] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142) >> [ 8.605600] ath10k_pci 0001:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0 >> [ 10.798574] ath10k_pci 0001:01:00.0: unable to read from the device >> [ 10.798598] ath10k_pci 0001:01:00.0: could not execute otp for board id check: -110 >> [ 10.803644] ath10k_pci 0001:01:00.0: failed to get board id from otp for qca99x0: -110 >> [ 10.811346] ath10k_pci 0001:01:00.0: could not probe fw (-110) >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k >
How about only ignoring the error only if there's caldata. Could be a good middle ground. This is a patch I submitted to OpenWRT a while ago as part of Netgear X4 support - https://patchwork.ozlabs.org/patch/601352/ On Wed, Apr 13, 2016 at 8:36 AM, Ben Greear <greearb@candelatech.com> wrote: > On 11/19/2015 10:21 AM, Sebastian Gottschall wrote: >> >> simple solution. >> >> as for ath9k. otp must be ignored for various chipsets, since they wont >> return valid results >> >> --- core.c (Revision 2702) >> +++ core.c (Arbeitskopie) >> @@ -1735,9 +1735,8 @@ >> >> ret = ath10k_core_get_board_id_from_otp(ar); >> if (ret && ret != -EOPNOTSUPP) { >> - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", >> + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, >> ignore\n", >> ret); >> - return ret; >> } >> >> ret = ath10k_core_fetch_board_file(ar); > > > I received a report of the same problem reported below from someone using an > i7 processor > on some random motherboard. > > Same NIC, kernel, and firmware works fine on my systems, so it appears to be > platform > dependent somehow. > > Did you find a better solution other than just ignoring the OTP failure? > > Thanks, > Ben > >> >> >> >> Am 19.11.2015 um 18:12 schrieb Sebastian Gottschall: >>> >>> Am 19.11.2015 um 17:13 schrieb Ben Greear: >>>> >>>> >>>> git clone git://dmz2.candelatech.com/linux.ath >>> >>> same effect with yours >>> >>> 6.201141] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142) >>> [ 6.201593] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 >>> irq_mode 0 reset_mode 0 >>> [ 8.578573] ath10k_pci 0000:01:00.0: unable to read from the device >>> [ 8.578605] ath10k_pci 0000:01:00.0: could not execute otp for board >>> id check: -110 >>> [ 8.583648] ath10k_pci 0000:01:00.0: failed to get board id from otp >>> for qca99x0: -110 >>> [ 8.591338] ath10k_pci 0000:01:00.0: could not probe fw (-110) >>> [ 8.600062] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142) >>> [ 8.605600] ath10k_pci 0001:01:00.0: pci irq legacy interrupts 0 >>> irq_mode 0 reset_mode 0 >>> [ 10.798574] ath10k_pci 0001:01:00.0: unable to read from the device >>> [ 10.798598] ath10k_pci 0001:01:00.0: could not execute otp for board >>> id check: -110 >>> [ 10.803644] ath10k_pci 0001:01:00.0: failed to get board id from otp >>> for qca99x0: -110 >>> [ 10.811346] ath10k_pci 0001:01:00.0: could not probe fw (-110) >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k
Am 13.04.2016 um 17:36 schrieb Ben Greear: > On 11/19/2015 10:21 AM, Sebastian Gottschall wrote: >> simple solution. >> >> as for ath9k. otp must be ignored for various chipsets, since they >> wont return valid results >> >> --- core.c (Revision 2702) >> +++ core.c (Arbeitskopie) >> @@ -1735,9 +1735,8 @@ >> >> ret = ath10k_core_get_board_id_from_otp(ar); >> if (ret && ret != -EOPNOTSUPP) { >> - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", >> + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, >> ignore\n", >> ret); >> - return ret; >> } >> >> ret = ath10k_core_fetch_board_file(ar); > > I received a report of the same problem reported below from someone > using an i7 processor > on some random motherboard. > > Same NIC, kernel, and firmware works fine on my systems, so it appears > to be platform > dependent somehow. > > Did you find a better solution other than just ignoring the OTP failure? nope. thats the only way and applies to all SOC devices using QCA998X chipsets. (routers etc.) they dont have a otp, so the call fails. all data is stored in local flash memory on this devices. i also have never seen this call working. no matter which card i used > > Thanks, > Ben > >> >> >> >> Am 19.11.2015 um 18:12 schrieb Sebastian Gottschall: >>> Am 19.11.2015 um 17:13 schrieb Ben Greear: >>>> >>>> git clone git://dmz2.candelatech.com/linux.ath >>> same effect with yours >>> >>> 6.201141] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142) >>> [ 6.201593] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 >>> irq_mode 0 reset_mode 0 >>> [ 8.578573] ath10k_pci 0000:01:00.0: unable to read from the device >>> [ 8.578605] ath10k_pci 0000:01:00.0: could not execute otp for >>> board id check: -110 >>> [ 8.583648] ath10k_pci 0000:01:00.0: failed to get board id from >>> otp for qca99x0: -110 >>> [ 8.591338] ath10k_pci 0000:01:00.0: could not probe fw (-110) >>> [ 8.600062] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142) >>> [ 8.605600] ath10k_pci 0001:01:00.0: pci irq legacy interrupts 0 >>> irq_mode 0 reset_mode 0 >>> [ 10.798574] ath10k_pci 0001:01:00.0: unable to read from the device >>> [ 10.798598] ath10k_pci 0001:01:00.0: could not execute otp for >>> board id check: -110 >>> [ 10.803644] ath10k_pci 0001:01:00.0: failed to get board id from >>> otp for qca99x0: -110 >>> [ 10.811346] ath10k_pci 0001:01:00.0: could not probe fw (-110) >>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > >
Am 13.04.2016 um 19:05 schrieb Alexis Green: > How about only ignoring the error only if there's caldata. Could be a > good middle ground. > > This is a patch I submitted to OpenWRT a while ago as part of Netgear > X4 support - > https://patchwork.ozlabs.org/patch/601352/ even then its not clear if this function ever worked. you say it happend on a I7 system. so a device without caldata on local flash memory > > On Wed, Apr 13, 2016 at 8:36 AM, Ben Greear <greearb@candelatech.com> wrote: >> On 11/19/2015 10:21 AM, Sebastian Gottschall wrote: >>> simple solution. >>> >>> as for ath9k. otp must be ignored for various chipsets, since they wont >>> return valid results >>> >>> --- core.c (Revision 2702) >>> +++ core.c (Arbeitskopie) >>> @@ -1735,9 +1735,8 @@ >>> >>> ret = ath10k_core_get_board_id_from_otp(ar); >>> if (ret && ret != -EOPNOTSUPP) { >>> - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", >>> + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, >>> ignore\n", >>> ret); >>> - return ret; >>> } >>> >>> ret = ath10k_core_fetch_board_file(ar); >> >> I received a report of the same problem reported below from someone using an >> i7 processor >> on some random motherboard. >> >> Same NIC, kernel, and firmware works fine on my systems, so it appears to be >> platform >> dependent somehow. >> >> Did you find a better solution other than just ignoring the OTP failure? >> >> Thanks, >> Ben >> >>> >>> >>> Am 19.11.2015 um 18:12 schrieb Sebastian Gottschall: >>>> Am 19.11.2015 um 17:13 schrieb Ben Greear: >>>>> >>>>> git clone git://dmz2.candelatech.com/linux.ath >>>> same effect with yours >>>> >>>> 6.201141] ath10k_pci 0000:01:00.0: enabling device (0140 -> 0142) >>>> [ 6.201593] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 >>>> irq_mode 0 reset_mode 0 >>>> [ 8.578573] ath10k_pci 0000:01:00.0: unable to read from the device >>>> [ 8.578605] ath10k_pci 0000:01:00.0: could not execute otp for board >>>> id check: -110 >>>> [ 8.583648] ath10k_pci 0000:01:00.0: failed to get board id from otp >>>> for qca99x0: -110 >>>> [ 8.591338] ath10k_pci 0000:01:00.0: could not probe fw (-110) >>>> [ 8.600062] ath10k_pci 0001:01:00.0: enabling device (0140 -> 0142) >>>> [ 8.605600] ath10k_pci 0001:01:00.0: pci irq legacy interrupts 0 >>>> irq_mode 0 reset_mode 0 >>>> [ 10.798574] ath10k_pci 0001:01:00.0: unable to read from the device >>>> [ 10.798598] ath10k_pci 0001:01:00.0: could not execute otp for board >>>> id check: -110 >>>> [ 10.803644] ath10k_pci 0001:01:00.0: failed to get board id from otp >>>> for qca99x0: -110 >>>> [ 10.811346] ath10k_pci 0001:01:00.0: could not probe fw (-110) >>>> >>>> >>>> _______________________________________________ >>>> ath10k mailing list >>>> ath10k@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k
--- core.c (Revision 2702) +++ core.c (Arbeitskopie) @@ -1735,9 +1735,8 @@ ret = ath10k_core_get_board_id_from_otp(ar); if (ret && ret != -EOPNOTSUPP) { - ath10k_err(ar, "failed to get board id from otp for qca99x0: %d\n", + ath10k_err(ar, "failed to get board id from otp for qca99x0: %d, ignore\n", ret); - return ret; }