From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 26225 invoked from network); 9 Jan 2021 23:35:35 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 9 Jan 2021 23:35:35 -0000
Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Sat Jan  9 18:09:15 -0500 2021
Message-ID: <B7D9832A601B87280FEB076260290D74@felloff.net>
Date: Sun, 10 Jan 2021 00:09:04 +0100
From: cinap_lenrek@felloff.net
To: 9front@9front.org
In-Reply-To: <06028168ED7BF4EA92B2E90BB23E173B@kamalatta.ddnss.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: progressive overflow-preventing firewall framework-aware lifecycle API 
Subject: Re: [9front] BUG: thinclient not booting with usbehci,usbohci
Reply-To: 9front@9front.org
Precedence: bulk

of course, please try.

i want to fix this for everyone, not just your personal machine :)

there might be some problems in the ehci or ohci initialization
that fails to recover the controller when busmaster has been
disabled before.

it would be great to investigate here instead of removing
the call to pcireset(), as it provides some safety.

the issue is that pci devices might be in a unknown state,
potentially fetching garbage dma descriptors from main memory
that we think is free to use.

the usual approach in drivers is to first reset the device
and bring it to a known state before enabling busmaster.

the call to pcireset() ensures that this is the case.
turn everything off, and then each driver carefully
reenables it when the device is ready.

maybe the first task would be to figure out which of the
controllers causes the problems (and which does does NOT).
if it is the ohci or ehci controllers.

we can selectively keep the busmaster on by editing
/sys/src/9/port/pci.c:

void
pcireset(void)
{
	Pcidev *p;

	for(p = pcilist; p != nil; p = p->list) {
		/* don't mess with the bridges */
		if(p->ccrb == 0x06)
			continue;

+		if(p->ccrb == Pcibcserial && p->ccru == Pciscusb){
+			switch(p->ccrp){
+			// case 0x30:	/* XHCI */
+			case 0x20:	/* EHCI */
+			// case 0x10:	/* OHCI */
+			// case 0x00:	/* UHCI */
+				continue;
+			}
+		}

		pcidisable(p);
	}
}

this skips the EHCI controllers, keeping its busmaster enable on.

in a second test, comment out the case 0x20 and remove comment
for case 0x10, so that the OHCI controller is kept untouched
instead of the ehci.

and last, try both cases...

that way we might be able to reduce the problem to one specifc
controller type and then start investigating there.

it is possible that when we disable the musmaster flag,
that the host controller gets a transaction abort and
raises an Host error that our driver didnt mask or clear
when our driver enables the device. this is what the
the other code from the preivous mail does.

--
cinap