From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Stefan Wahren <stefan.wahren@i2se.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: Thu, 14 Feb 2019 10:54:20 +0100 [thread overview]
Message-ID: <20190214095420.GB17273@redhat.com> (raw)
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.
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Stefan Wahren <stefan.wahren@i2se.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: Thu, 14 Feb 2019 10:54:20 +0100 [thread overview]
Message-ID: <20190214095420.GB17273@redhat.com> (raw)
In-Reply-To: <878a7160-2e91-d057-6d27-c6b9d85f700e@i2se.com>
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.
> 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
next reply other threads:[~2019-02-14 9:54 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 9:54 Stanislaw Gruszka [this message]
2019-02-14 9:54 ` [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ Stanislaw Gruszka
-- strict thread matches above, loose matches on Subject: below --
2019-03-03 21:16 Stefan Wahren
2019-03-03 21:16 ` Stefan Wahren
2019-02-20 16:36 Lorenzo Bianconi
2019-02-20 16:36 ` Lorenzo Bianconi
2019-02-20 16:32 Stanislaw Gruszka
2019-02-20 16:32 ` Stanislaw Gruszka
2019-02-20 16:22 Lorenzo Bianconi
2019-02-20 16:22 ` Lorenzo Bianconi
2019-02-20 16:14 Stanislaw Gruszka
2019-02-20 16:14 ` Stanislaw Gruszka
2019-02-20 15:25 Alan Stern
2019-02-20 15:25 ` Alan Stern
2019-02-20 13:22 Lorenzo Bianconi
2019-02-20 13:22 ` Lorenzo Bianconi
2019-02-20 13:00 Stanislaw Gruszka
2019-02-20 13:00 ` Stanislaw Gruszka
2019-02-20 10:20 Stanislaw Gruszka
2019-02-20 10:20 ` Stanislaw Gruszka
2019-02-19 17:02 Stefan Wahren
2019-02-19 17:02 ` Stefan Wahren
2019-02-19 15:40 Alan Stern
2019-02-19 15:40 ` Alan Stern
2019-02-19 12:19 Felix Fietkau
2019-02-19 12:19 ` Felix Fietkau
2019-02-19 12:11 Felix Fietkau
2019-02-19 12:11 ` Felix Fietkau
2019-02-19 10:59 Stanislaw Gruszka
2019-02-19 10:59 ` Stanislaw Gruszka
2019-02-19 10:42 Stanislaw Gruszka
2019-02-19 10:42 ` Stanislaw Gruszka
2019-02-18 22:19 Stefan Wahren
2019-02-18 22:19 ` Stefan Wahren
2019-02-18 18:52 Felix Fietkau
2019-02-18 18:52 ` Felix Fietkau
2019-02-18 15:03 Stanislaw Gruszka
2019-02-18 15:03 ` Stanislaw Gruszka
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 14:25 Lorenzo Bianconi
2019-02-18 14:25 ` Lorenzo Bianconi
2019-02-18 13:52 Stanislaw Gruszka
2019-02-18 13:52 ` Stanislaw Gruszka
2019-02-16 19:17 Stefan Wahren
2019-02-16 19:17 ` Stefan Wahren
2019-02-16 14:07 Stanislaw Gruszka
2019-02-16 14:07 ` Stanislaw Gruszka
2019-02-16 11:05 Stefan Wahren
2019-02-16 11:05 ` Stefan Wahren
2019-02-15 7:12 Stanislaw Gruszka
2019-02-15 7:12 ` Stanislaw Gruszka
2019-02-14 9:48 Stefan Wahren
2019-02-14 9:48 ` Stefan Wahren
2019-02-14 9:25 Stanislaw Gruszka
2019-02-14 9:25 ` Stanislaw Gruszka
2019-02-14 6:49 Stefan Wahren
2019-02-14 6:49 ` Stefan Wahren
2019-02-13 7:05 Stefan Wahren
2019-02-13 7:05 ` Stefan Wahren
2019-02-12 15:27 Alan Stern
2019-02-12 15:27 ` Alan Stern
2019-02-12 13:15 Stanislaw Gruszka
2019-02-12 13:15 ` Stanislaw Gruszka
2019-02-12 11:58 Lorenzo Bianconi
2019-02-12 11:58 ` Lorenzo Bianconi
2019-02-12 9:30 Stanislaw Gruszka
2019-02-12 9:30 ` Stanislaw Gruszka
2019-02-12 0:06 Lorenzo Bianconi
2019-02-12 0:06 ` Lorenzo Bianconi
2019-02-11 17:49 Alan Stern
2019-02-11 17:33 Stanislaw Gruszka
2019-02-11 17:22 Stanislaw Gruszka
2019-02-11 17:22 ` Stanislaw Gruszka
2019-02-11 15:57 Lorenzo Bianconi
2019-02-11 15:57 ` Lorenzo Bianconi
2019-02-11 15:27 Stefan Wahren
2019-02-11 15:27 ` Stefan Wahren
2019-02-11 15:12 Alan Stern
2019-02-11 15:10 Lorenzo Bianconi
2019-02-11 15:10 ` Lorenzo Bianconi
2019-02-11 14:04 Stefan Wahren
2019-02-11 14:04 ` Stefan Wahren
2019-02-11 11:06 Lorenzo Bianconi
2019-02-11 11:06 ` Lorenzo Bianconi
2019-02-11 10:33 Stefan Wahren
2019-02-11 10:33 ` Stefan Wahren
2019-02-11 10:04 Lorenzo Bianconi
2019-02-11 10:04 ` Lorenzo Bianconi
2019-02-11 7:44 Stanislaw Gruszka
2019-02-11 7:44 ` Stanislaw Gruszka
2019-02-10 17:39 Lorenzo Bianconi
2019-02-10 17:39 ` Lorenzo Bianconi
2019-02-10 10:22 Lorenzo Bianconi
2019-02-10 10:22 ` Lorenzo Bianconi
2019-02-10 9:41 Stanislaw Gruszka
2019-02-10 9:41 ` Stanislaw Gruszka
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:29 ` Stanislaw Gruszka
2019-02-10 16:38 ` Stefan Wahren
2019-02-10 16:52 ` 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=20190214095420.GB17273@redhat.com \
--to=sgruszka@redhat.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=stefan.wahren@i2se.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: link
Be 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.