On Thu, Feb 14, 2019 at 10:48:15AM +0100, Stefan Wahren wrote: > Hi Stanislaw, > > Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka: > > On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote: > >> Hi Stanislaw, > >> > >>> Stanislaw Gruszka <sgruszka@xxxxxxxxxx> hat am 12. Februar 2019 um 10:30 geschrieben: > >>> > >>> > >>> > >>> In usb_sg_init() urb->num_sgs is set 0 for sg_tablesize = 0 controllers. > >>> In mt76 we set urb->num_sgs to 1. I thought it is fine, but now I think > >>> this is bug. We can fix that without changing allocation method and > >>> still use SG allocation. Attached patch do this, please check if it works > >>> on rpi. Patch is on top of your error path fixes. > >> your patch didn't apply cleanly to yesterdays next. After some minor manual fixup, i was able to build them and here are the results starting from boot (please ignore the invalid time in the kernel log): > >> https://gist.github.com/lategoodbye/33bd5bc75b9fc935faa231bc472defa8 > > I think this is due to urb->transfer_length and sg[0]->length mismatch, > > which should be addressed by my other patch. I'm attaching the patch > > rebased on -next with this line integrated, please test. > > > > But there could be other bug's in mt76-usb SG code. > Will retry > > > >> Using multi_v7_defconfig i'm getting a warning on the first connect and always this flood of rx urb failed on disconnect. The driver seems to probe but isn't functional even after 2 tries. > >> > >> Using arm64_defconfig i don't get any warning. But except of this i'm getting similiar results to multi_v7_defconfig. > >> > >> So in comparison, Lorenzo's workaround behaves better. > > I'm pretty sure problem is mt76x0u 4.19 -> 4.20 regression intrduced by > > integrating mt76x0u in mt76-usb (things do not work from day 0 > > for mt76x2u). We should find fix(es) that will be proper for -stable. > So i should also try 4.19 without any patches? That would be good. Thanks. Stanislaw
