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? > > Stanislaw
