Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Ross Zwisler <zwisler@google.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"kernel@collabora.com" <kernel@collabora.com>
Subject: Re: xhci problem -> general protection fault
Date: Fri, 4 Dec 2020 20:07:30 +0200
Message-ID: <b6eba37b-c78b-fc99-5aca-f9e5856e80ac@linux.intel.com> (raw)
In-Reply-To: <CAGRrVHwgxtPF89niHV3N58SaDb7q5jWde_g7-yVxGPcKhemsaw@mail.gmail.com>

On 3.12.2020 0.59, Ross Zwisler wrote:
> On Mon, Nov 23, 2020 at 8:04 AM Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
> 
>> I think I got most of the functionality now working.
>> The series is not in upstream shape, but should work, and can be tested.
>> just pushed it to a rewrite_halt_stop_handling branch in my tree, ten patches on top of 5.10-rc4
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git rewrite_halt_stop_handling
>> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=rewrite_halt_stop_handling
>>
>> It still contains dead code that needs to be removed, and all streams (uas) cases are not
>> handled properly, it won't pass checkpatch.. and so on,  but it should be testable.
>>
>> Thanks
>> -Mathias
> 
> Unfortunately I'm still able to reproduce the failure with your
> patches.  Here is a dmesg:
> 
> https://gist.github.com/rzwisler/05e52020e87f0ccd6185182be999dae0
> 
> I was testing at this commit:
> 
> 3c1f3ab219e5f xhci: handle halting transfer event properly after
> endpoint stop and halt raced.
> 
> Turning on ftrace makes it much harder to reproduce.  Should I keep
> trying for a repro with tracing turned on, or is the fact that it
> still happens informative enough to know we have to look elsewhere for
> a solution?
> 
> Thanks,
> - Ross
> 

Ok, thanks.

Then the rootcause remains unknown.
For some reason the endpoint context dequeue pointer field contains zero
instead of the new dequeue pointer.
The (output) endpoint context is supposed to be written only by the controller.

Time to change strategy and start to detect and treat the symptoms instead.

I wrote a patch that detects the 0-dequeue pointer and issues a
new Set TR Deq pointer command. Hopefully that works.
patch added to same branch, can you try it out?

3f6326766abc xhci: retry setting new dequeue if xHC hardware failed to update it

I didn't set a retry limit yet so if it doesn't work it might retry forever.
 
Thanks
Mathias

  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 15:30 Andrzej Pietrasiewicz
2020-09-18 10:50 ` Mathias Nyman
2020-09-18 14:20   ` Andrzej Pietrasiewicz
2020-09-25 13:40     ` Mathias Nyman
2020-09-25 21:05       ` Ross Zwisler
2020-09-28 13:32         ` Andrzej Pietrasiewicz
2020-09-29  7:13           ` Mathias Nyman
2020-10-01 14:13             ` Andrzej Pietrasiewicz
2020-09-28 22:35         ` Mathias Nyman
2020-10-01 16:43           ` zwisler
2020-10-12 19:20             ` Mathias Nyman
2020-10-12 21:53               ` zwisler
2020-10-13  7:49                 ` Mathias Nyman
2020-10-13  8:29                   ` Andrzej Pietrasiewicz
2020-10-13 16:44                     ` zwisler
2020-11-19 16:52                   ` Ross Zwisler
2020-11-23 15:06                     ` Mathias Nyman
2020-12-02 22:59                       ` Ross Zwisler
2020-12-04 18:07                         ` Mathias Nyman [this message]
2020-12-08 17:24                           ` Ross Zwisler
2020-12-09 13:11                             ` Mathias Nyman
2020-12-09 18:54                               ` Ross Zwisler
2020-12-30 12:33                                 ` Mathias Nyman
2021-01-06 18:52                                   ` Ross Zwisler
2021-01-07  8:57                                     ` Mathias Nyman
2021-01-07 16:07                                       ` Ross Zwisler

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=b6eba37b-c78b-fc99-5aca-f9e5856e80ac@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=andrzej.p@collabora.com \
    --cc=kernel@collabora.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=zwisler@google.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

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git