linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	Felix Fietkau <nbd@nbd.name>,
	Doug Anderson <dianders@chromium.org>,
	Minas Harutyunyan <hminas@synopsys.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	linux-usb@vger.kernel.org
Subject: Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
Date: Mon, 11 Feb 2019 08:44:56 +0100	[thread overview]
Message-ID: <20190211074455.GA6292@redhat.com> (raw)
In-Reply-To: <CAJ0CqmXp2a-zwPMyMFu+UCqTHP7qNRiJFopDSdZWdms7dVef4Q@mail.gmail.com>

On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
> > On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
> > > > could you please test the following series:
> > > > https://patchwork.kernel.org/cover/10764453/
> > >
> > > yeah this fixed the probing timeout and the driver will probe successful. AFAIK the dwc2 host mode doesn't support scatter-gather yet.
> >
> > So this is either dwc2 scatter-gather problem which should be addressed in
> > this driver or mt76x0u does something wrong when configuring SG.
> >
> > Disabling SG is just workaround, which do not address actual problem.
> >
> > I think I found mt76x0u issue that could cause this USB probe error
> > (and possibly also address AMD IOMMU issue). We seems do not correctly
> > set URB transfer length smaller than sg buffer length. Attached  patch
> > should correct that.
> 
> Hi Stanislaw,
> 
> I think 'sg[0].length' is already set in mt76u_fill_rx_sg().

It is, buf->len and sg[0].length are initialized to the same value for 1
segment. But then buf->len (assigned to urb->buffer_transfer_length) change
to smaller value , but sg[0].length stay the same. What I think can be
problem for usb host driver.

> Moreover applying this patch I got the following crash (rpi-5.0.y):

Ok, so with patch probe fail instantly and trigger yet another bug(s)
on error path. You seems to address that already. 

> Moreover for mt76x0u SG is 'already' disabled since we use just one
> buffer so from performance point of view I do not see any difference
> of using a standard usb buffer.
> This patch has been tested in multiple scenarios and seems to fix
> reported issues (for usb2.0).

Ok, so passing buffer via urb->transfer_buffer works. But why urb->sg
does not work for 1 segment ?

> Are you concerned about increasing code complexity?

That's one of my concerns. Another, more important one, is that
changing to urb->transfer_buffer just hide the problems. And they will
pop up when someone will start to use SG (BTW how this can be tested
for more than one fragment, IOW how multiple fragments skb's can
be generated ? ).

And now I think the bugs can be in mt76 driver taking that problems
happened on different platforms (rpi and AMD IOMMU), i.e. we do not
correctly set urb->nub_seg or length or do some other thing wrong.

Stanislaw

  reply	other threads:[~2019-02-11  7:45 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09 12:08 [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+ 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 10:22       ` Lorenzo Bianconi
2019-02-11  7:44         ` Stanislaw Gruszka [this message]
2019-02-11 10:04           ` Lorenzo Bianconi
2019-02-11 10:33             ` Stefan Wahren
2019-02-11 11:06               ` Lorenzo Bianconi
2019-02-11 14:04                 ` Stefan Wahren
2019-02-11 15:10                   ` Lorenzo Bianconi
2019-02-11 15:27                     ` Stefan Wahren
2019-02-11 15:57                       ` Lorenzo Bianconi
2019-02-13  7:05                         ` Stefan Wahren
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-11  7:50         ` Stanislaw Gruszka
2019-02-11  8:08           ` Stefan Wahren
2019-02-11  9:52             ` Lorenzo Bianconi
     [not found] <20190211173315.GE6292@redhat.com>
     [not found] ` <Pine.LNX.4.44L0.1902111246410.1543-100000@iolanthe.rowland.org>
2019-02-12  0:06   ` Lorenzo Bianconi
2019-02-12  9:30     ` Stanislaw Gruszka
2019-02-12 11:58       ` Lorenzo Bianconi
2019-02-12 13:15         ` Stanislaw Gruszka
2019-02-14  6:49       ` Stefan Wahren
2019-02-14  9:25         ` Stanislaw Gruszka
2019-02-14  9:48           ` Stefan Wahren
2019-02-14  9:54             ` Stanislaw Gruszka
2019-02-15  7:12             ` Stanislaw Gruszka
2019-02-16 11:05               ` Stefan Wahren
2019-02-16 14:07                 ` Stanislaw Gruszka
2019-02-16 19:17                   ` Stefan Wahren
2019-02-18 13:52                     ` Stanislaw Gruszka
2019-02-18 14:25                       ` Lorenzo Bianconi
2019-02-18 14:47                         ` Stanislaw Gruszka
2019-02-18 14:43                       ` Felix Fietkau
2019-02-18 15:03                         ` Stanislaw Gruszka
2019-02-18 18:52                           ` Felix Fietkau
2019-02-19 10:42                             ` Stanislaw Gruszka
2019-02-19 12:19                               ` Felix Fietkau
2019-02-20 13:00                                 ` Stanislaw Gruszka
2019-02-20 13:22                                   ` Lorenzo Bianconi
2019-02-20 16:14                                     ` Stanislaw Gruszka
2019-02-20 16:22                                       ` Lorenzo Bianconi
2019-02-20 16:32                                         ` Stanislaw Gruszka
2019-02-20 16:36                                           ` Lorenzo Bianconi
2019-03-03 21:16                                           ` Stefan Wahren
2019-02-18 22:19                       ` Stefan Wahren
2019-02-19 10:59                         ` Stanislaw Gruszka
2019-02-19 12:11                           ` Felix Fietkau
2019-02-19 15:40                           ` Alan Stern
2019-02-20 10:20                             ` Stanislaw Gruszka
2019-02-20 15:25                               ` Alan Stern
2019-02-19 17:02                           ` Stefan Wahren
2019-02-12 15:27     ` Alan Stern

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=20190211074455.GA6292@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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).