From: Stefan Wahren <stefan.wahren@i2se.com> To: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>, Alan Stern <stern@rowland.harvard.edu>, Felix Fietkau <nbd@nbd.name>, Doug Anderson <dianders@chromium.org>, Minas Harutyunyan <hminas@synopsys.com>, USB list <linux-usb@vger.kernel.org>, linux-wireless <linux-wireless@vger.kernel.org> Subject: Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Date: Sat, 16 Feb 2019 12:05:18 +0100 (CET) [thread overview] Message-ID: <1411983628.668277.1550315118443@email.ionos.de> (raw) In-Reply-To: <20190215071226.GA2372@redhat.com> Hi Stanislaw, > Stanislaw Gruszka <sgruszka@redhat.com> hat am 15. Februar 2019 um 08:12 geschrieben: > > > 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@redhat.com> 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. > > I found another bug in mt76usb SG code. We set sg->offset bigger than > PAGE_SIZE that actually make sg point to memory in different page than > sg->page. Correcting this with another patch that avoid using sg > mapping with sg->length > PAGE_SIZE, fixed mt76x0u with AMD IOMMU: > https://bugzilla.kernel.org/show_bug.cgi?id=202241 > > I'm attaching 3 patches, they should also fix issue on rpi. > It's also possible that only 2 patches are sufficient: > > 0001-mt76usb-do-not-set-urb-num_sgs-to-1-for-non-SG-usb-h.patch > 0003-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch > > to fix the issue, if doing dma_map_{page,sg} is fine with > sg->offset == 0 and sg->length bigger than one page. > > Please test, thanks. > sorry for the delay, but i do this all in my spare time. The results for your recent patch series are better (no firmware timeout), but still no working wifi and still a warning: https://gist.github.com/lategoodbye/c4864e446821717419cbe65df07f8d8d I've identified the reason for the warning in dwc2: /* * We assume that DMA is always aligned in non-split * case or split out case. Warn if not. */ WARN_ON_ONCE(hsotg->params.host_dma && (chan->xfer_dma & 0x3)); Btw i can confirm a regression was introduced after 4.19, because in 4.19 there was no firmware timeout but even no working wifi: Feb 15 19:10:51 raspberrypi kernel: [ 79.818414] usb 1-1.3: new high-speed USB device number 6 using dwc2 Feb 15 19:10:51 raspberrypi kernel: [ 80.178470] usb 1-1.3: reset high-speed USB device number 6 using dwc2 Feb 15 19:10:51 raspberrypi kernel: [ 80.314388] mt76x0 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000 Feb 15 19:10:52 raspberrypi kernel: [ 81.118751] BBP version f000f200 Feb 15 19:10:52 raspberrypi kernel: [ 81.152995] mt76x0 1-1.3:1.0: EEPROM ver:02 fae:01 Feb 15 19:10:52 raspberrypi kernel: [ 81.153232] mt76x0 1-1.3:1.0: EEPROM country region 01 (channels 1-13) Feb 15 19:10:52 raspberrypi kernel: [ 81.176968] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Feb 15 19:10:52 raspberrypi kernel: [ 81.178255] usbcore: registered new interface driver mt76x0 Feb 15 19:10:53 raspberrypi kernel: [ 81.578982] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Stefan > Stanislaw
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Wahren <stefan.wahren@i2se.com> To: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>, Alan Stern <stern@rowland.harvard.edu>, Felix Fietkau <nbd@nbd.name>, Doug Anderson <dianders@chromium.org>, Minas Harutyunyan <hminas@synopsys.com>, USB list <linux-usb@vger.kernel.org>, linux-wireless <linux-wireless@vger.kernel.org> Subject: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Date: Sat, 16 Feb 2019 12:05:18 +0100 (CET) [thread overview] Message-ID: <1411983628.668277.1550315118443@email.ionos.de> (raw) Hi Stanislaw, > Stanislaw Gruszka <sgruszka@redhat.com> hat am 15. Februar 2019 um 08:12 geschrieben: > > > 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@redhat.com> 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. > > I found another bug in mt76usb SG code. We set sg->offset bigger than > PAGE_SIZE that actually make sg point to memory in different page than > sg->page. Correcting this with another patch that avoid using sg > mapping with sg->length > PAGE_SIZE, fixed mt76x0u with AMD IOMMU: > https://bugzilla.kernel.org/show_bug.cgi?id=202241 > > I'm attaching 3 patches, they should also fix issue on rpi. > It's also possible that only 2 patches are sufficient: > > 0001-mt76usb-do-not-set-urb-num_sgs-to-1-for-non-SG-usb-h.patch > 0003-mt76usb-do-not-use-compound-head-page-for-SG-I-O.patch > > to fix the issue, if doing dma_map_{page,sg} is fine with > sg->offset == 0 and sg->length bigger than one page. > > Please test, thanks. > sorry for the delay, but i do this all in my spare time. The results for your recent patch series are better (no firmware timeout), but still no working wifi and still a warning: https://gist.github.com/lategoodbye/c4864e446821717419cbe65df07f8d8d I've identified the reason for the warning in dwc2: /* * We assume that DMA is always aligned in non-split * case or split out case. Warn if not. */ WARN_ON_ONCE(hsotg->params.host_dma && (chan->xfer_dma & 0x3)); Btw i can confirm a regression was introduced after 4.19, because in 4.19 there was no firmware timeout but even no working wifi: Feb 15 19:10:51 raspberrypi kernel: [ 79.818414] usb 1-1.3: new high-speed USB device number 6 using dwc2 Feb 15 19:10:51 raspberrypi kernel: [ 80.178470] usb 1-1.3: reset high-speed USB device number 6 using dwc2 Feb 15 19:10:51 raspberrypi kernel: [ 80.314388] mt76x0 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000 Feb 15 19:10:52 raspberrypi kernel: [ 81.118751] BBP version f000f200 Feb 15 19:10:52 raspberrypi kernel: [ 81.152995] mt76x0 1-1.3:1.0: EEPROM ver:02 fae:01 Feb 15 19:10:52 raspberrypi kernel: [ 81.153232] mt76x0 1-1.3:1.0: EEPROM country region 01 (channels 1-13) Feb 15 19:10:52 raspberrypi kernel: [ 81.176968] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Feb 15 19:10:52 raspberrypi kernel: [ 81.178255] usbcore: registered new interface driver mt76x0 Feb 15 19:10:53 raspberrypi kernel: [ 81.578982] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Stefan > Stanislaw
next prev parent reply other threads:[~2019-02-16 11:05 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-11 17:33 [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Stanislaw Gruszka 2019-02-11 17:49 ` Alan Stern 2019-02-12 0:06 ` Lorenzo Bianconi 2019-02-12 0:06 ` Lorenzo Bianconi 2019-02-12 9:30 ` Stanislaw Gruszka 2019-02-12 9:30 ` Stanislaw Gruszka 2019-02-12 11:58 ` Lorenzo Bianconi 2019-02-12 11:58 ` Lorenzo Bianconi 2019-02-12 13:15 ` Stanislaw Gruszka 2019-02-12 13:15 ` Stanislaw Gruszka 2019-02-14 6:49 ` Stefan Wahren 2019-02-14 6:49 ` Stefan Wahren 2019-02-14 9:25 ` Stanislaw Gruszka 2019-02-14 9:25 ` Stanislaw Gruszka 2019-02-14 9:48 ` Stefan Wahren 2019-02-14 9:48 ` Stefan Wahren 2019-02-14 9:54 ` Stanislaw Gruszka 2019-02-14 9:54 ` Stanislaw Gruszka 2019-02-15 7:12 ` Stanislaw Gruszka 2019-02-15 7:12 ` Stanislaw Gruszka 2019-02-16 11:05 ` Stefan Wahren [this message] 2019-02-16 11:05 ` Stefan Wahren 2019-02-16 14:07 ` Stanislaw Gruszka 2019-02-16 14:07 ` Stanislaw Gruszka 2019-02-16 19:17 ` Stefan Wahren 2019-02-16 19:17 ` Stefan Wahren 2019-02-18 13:52 ` Stanislaw Gruszka 2019-02-18 13:52 ` Stanislaw Gruszka 2019-02-18 14:25 ` Lorenzo Bianconi 2019-02-18 14:25 ` Lorenzo Bianconi 2019-02-18 14:47 ` Stanislaw Gruszka 2019-02-18 14:47 ` Stanislaw Gruszka 2019-02-18 14:43 ` Felix Fietkau 2019-02-18 14:43 ` Felix Fietkau 2019-02-18 15:03 ` Stanislaw Gruszka 2019-02-18 15:03 ` Stanislaw Gruszka 2019-02-18 18:52 ` Felix Fietkau 2019-02-18 18:52 ` Felix Fietkau 2019-02-19 10:42 ` Stanislaw Gruszka 2019-02-19 10:42 ` Stanislaw Gruszka 2019-02-19 12:19 ` Felix Fietkau 2019-02-19 12:19 ` Felix Fietkau 2019-02-20 13:00 ` Stanislaw Gruszka 2019-02-20 13:00 ` Stanislaw Gruszka 2019-02-20 13:22 ` Lorenzo Bianconi 2019-02-20 13:22 ` Lorenzo Bianconi 2019-02-20 16:14 ` Stanislaw Gruszka 2019-02-20 16:14 ` Stanislaw Gruszka 2019-02-20 16:22 ` Lorenzo Bianconi 2019-02-20 16:22 ` Lorenzo Bianconi 2019-02-20 16:32 ` Stanislaw Gruszka 2019-02-20 16:32 ` Stanislaw Gruszka 2019-02-20 16:36 ` Lorenzo Bianconi 2019-02-20 16:36 ` Lorenzo Bianconi 2019-03-03 21:16 ` Stefan Wahren 2019-03-03 21:16 ` Stefan Wahren 2019-02-18 22:19 ` Stefan Wahren 2019-02-18 22:19 ` Stefan Wahren 2019-02-19 10:59 ` Stanislaw Gruszka 2019-02-19 10:59 ` Stanislaw Gruszka 2019-02-19 12:11 ` Felix Fietkau 2019-02-19 12:11 ` Felix Fietkau 2019-02-19 15:40 ` Alan Stern 2019-02-19 15:40 ` Alan Stern 2019-02-20 10:20 ` Stanislaw Gruszka 2019-02-20 10:20 ` Stanislaw Gruszka 2019-02-20 15:25 ` Alan Stern 2019-02-20 15:25 ` Alan Stern 2019-02-19 17:02 ` Stefan Wahren 2019-02-19 17:02 ` Stefan Wahren 2019-02-12 15:27 ` Alan Stern 2019-02-12 15:27 ` Alan Stern -- strict thread matches above, loose matches on Subject: below -- 2019-02-11 15:12 Alan Stern 2019-02-09 12:08 Stefan Wahren 2019-02-09 18:46 ` Lorenzo Bianconi 2019-02-09 20:29 ` Stefan Wahren 2019-02-09 20:33 ` Lorenzo Bianconi 2019-02-09 22:47 ` Stefan Wahren 2019-02-10 9:41 ` Stanislaw Gruszka 2019-02-10 9:41 ` Stanislaw Gruszka 2019-02-10 10:22 ` Lorenzo Bianconi 2019-02-10 10:22 ` Lorenzo Bianconi 2019-02-11 7:44 ` Stanislaw Gruszka 2019-02-11 7:44 ` Stanislaw Gruszka 2019-02-11 10:04 ` Lorenzo Bianconi 2019-02-11 10:04 ` Lorenzo Bianconi 2019-02-11 10:33 ` Stefan Wahren 2019-02-11 10:33 ` Stefan Wahren 2019-02-11 11:06 ` Lorenzo Bianconi 2019-02-11 11:06 ` Lorenzo Bianconi 2019-02-11 14:04 ` Stefan Wahren 2019-02-11 14:04 ` Stefan Wahren 2019-02-11 15:10 ` Lorenzo Bianconi 2019-02-11 15:10 ` Lorenzo Bianconi 2019-02-11 15:27 ` Stefan Wahren 2019-02-11 15:27 ` Stefan Wahren 2019-02-11 15:57 ` Lorenzo Bianconi 2019-02-11 15:57 ` Lorenzo Bianconi 2019-02-13 7:05 ` Stefan Wahren 2019-02-13 7:05 ` Stefan Wahren 2019-02-11 17:22 ` Stanislaw Gruszka 2019-02-11 17:22 ` Stanislaw Gruszka 2019-02-10 9:29 ` Stanislaw Gruszka 2019-02-10 16:38 ` Stefan Wahren 2019-02-10 16:52 ` Lorenzo Bianconi 2019-02-10 17:39 ` Lorenzo Bianconi 2019-02-10 17:39 ` Lorenzo Bianconi 2019-02-11 7:50 ` Stanislaw Gruszka 2019-02-11 8:08 ` Stefan Wahren 2019-02-11 9:52 ` Lorenzo Bianconi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1411983628.668277.1550315118443@email.ionos.de \ --to=stefan.wahren@i2se.com \ --cc=dianders@chromium.org \ --cc=hminas@synopsys.com \ --cc=linux-usb@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=lorenzo.bianconi@redhat.com \ --cc=nbd@nbd.name \ --cc=sgruszka@redhat.com \ --cc=stern@rowland.harvard.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.