[9front] BUG: thinclient not booting with usbehci,usbohci

[9front] BUG: thinclient not booting with usbehci,usbohci

[stevie]

[no matches in 408 files]
Hi,

As of now two of my thinclients (HP t610 and Fujitsu Siemens S700) won't boot with any kernel after I updated the sources November 28th 2020.

The box freezes after the usbohci: messages: [1]

With *nousbehci and *nousbohci in plan9.ini the box boots and leaves me with the remaining xhci ports.

Sysinfo HP t610 [2]
Sysinfo Fujitsu Siemens S700 [3]
plan9.ini: [4]

I'd be happy to help to solve this problem  and will give further information when needed.

-- stevie

Re: [9front] BUG: thinclient not booting with usbehci,usbohci

[stevie]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

[1] http://kamalatta.ddnss.de/sys/hp-boot-freeze.jpg
[2] http://kamalatta.ddnss.de/sys/HP-t610-sysinfo.txt
[3] http://kamalatta.ddnss.de/sys/FUJI-700-sysinfo.txt
[4] http://kamalatta.ddnss.de/sys/HP-t610.plan9.ini

Sorry forgot the important part

[-- Attachment #2: Type: message/rfc822, Size: 2336 bytes --]

From: stevie@kamalatta.ddnss.de
To: 9front@9front.org
Subject: [9front] BUG: thinclient not booting with usbehci,usbohci
Date: Sat, 9 Jan 2021 10:22:28 +0100
Message-ID: <76802DE0593D549CE69A6B6B8008B163@kamalatta.ddnss.de>

[no matches in 408 files]
Hi,

As of now two of my thinclients (HP t610 and Fujitsu Siemens S700) won't boot with any kernel after I updated the sources November 28th 2020.

The box freezes after the usbohci: messages: [1]

With *nousbehci and *nousbohci in plan9.ini the box boots and leaves me with the remaining xhci ports.

Sysinfo HP t610 [2]
Sysinfo Fujitsu Siemens S700 [3]
plan9.ini: [4]

I'd be happy to help to solve this problem  and will give further information when needed.

-- stevie

Re: [9front] BUG: thinclient not booting with usbehci,usbohci

[cinap_lenrek]

interesting.

one thing that could cause this might be that the firmware
has still control over the usb controllers for ps2 emulation.

a while ago, our pci startup code now clears the busmaster
enable of all pci devices on boot. i wonder if this causes
the problems later on when we do the handoff.

you can try commenting out the call to pcireset() in
/sys/src/9/pc/pcipc.c in the pcicfginit() function?

	if(pciroot == nil)
		goto out;

-	pcireset();
+	// pcireset();

	if(nobios) {

we might also try making sure we clear interrupt enables
and interrupt status bits in ehci and ohci reset()
functions. it is possible that firmware has some
pending interrupts which are somehow left enabled
and not cleared by the controller reset.

for usbohci.c, that would be adding the following lines
to ohcireset() function:

	delay(100);
+	ctlr->ohci->intrdisable = Mie;
+	ctlr->ohci->intrenable = 0;
+	ctlr->ohci->intrsts = ctlr->ohci->intrsts & ~Mie;
	ctlr->ohci->control = 0;

and for usbehcipc.c, in ehcireset() function:

	/* reclaim from bios */
	getehci(ctlr);

+	/* disable interrupts */
+	opio->intr = 0;
+	opio->sts = opio->sts & Sintrs;

	/*
	 * halt and route ports to companion controllers
	 * until we are setup
	 */
	ehcirun(ctlr, 0);

also it would be nice if we could narrow it down to
eigther ohci or the ehci controllers.

--
cinap

Re: [9front] BUG: thinclient not booting with usbehci,usbohci

[stevie]

hi cinap,

I commented out the pcireset() function and recompiled the kernel. Booted fine for now. Many thanks!
I can test your other tips one for one if you think that it would be useful.

-- stevie

*e820=1 0x0000000000000000 0x000000000009e800 2 0x000000000009e800 0x00000000000
a0000 2 0x00000000000e0000 0x0000000000100000 1 0x0000000000100000 0x000000009c9
15000 2 0x000000009c915000 0x000000009c945000 3 0x000000009c945000 0x000000009c9
60000 4 0x000000009c960000 0x000000009ca56000 2 0x000000009ca56000 0x000000009e0
c9000 1 0x000000009e0c9000 0x000000009e0ca000 4 0x000000009e0ca000 0x000000009e0
d2000 1 0x000000009e0d2000 0x000000009e22d000 2 0x000000009e22d000 0x000000009e8
ae000 1 0x000000009e8ae000 0x000000009e8f0000 2 0x000000009e8f0000 0x000000009ef
f1000 1 0x000000009eff1000 0x000000009f000000 1 0x0000000100001000 0x000000013f0
00000 2 0x00000000fec00000 0x00000000fec02000 2 0x00000000fec10000 0x00000000fec
11000 2 0x00000000fed00000 0x00000000fed01000 2 0x00000000fed40000 0x00000000fed
45000 2 0x00000000fed80000 0x00000000fed90000 2 0x00000000ff000000 0x00000001000
00000                                                                           
bootfile=/amd64/9pc64                                                           
bootargs=tls                                                                    
nobootprompt=tls                                                                
auth=192.168.178.36                                                             
fs=192.168.178.36                                                               
monitor=vesa                                                                    
mouseport=ps2intellimouse                                                       
vgasize=1400x1050x32                                                            
*acpi=1                                                                         
ramdisk0=2048m                                                                  
cfs=#S/sdZ0/data                                                                
boot                                                                            

Plan 9
124 holes free
0x00024000 0x00083000 389120
0x00084000 0x0009e000 106496
0x00100000 0x00110000 65536
0x005f1000 0x1c915000 473055232
473616384 bytes free
pcirouting: ignoring south bridge PCI.0.20.3 1022/780E
cpu0: 1647MHz AuthenticAMD unknown (AX 00700F01 CX 36D8220B DX 178BFBFF)
ioalloc: cd6 - cd7 \_SB.PMIO: clashes with: cd6 - cd7 \PMIO
amlmapio: ioalloc failed
amlmapio: mapping \_SB.PMIO failed
LAPIC: fee00000 0xffffff00fee00000
ELCR: 0C30
cpu0: lapic clock at 100MHz
cpu1: 1647MHz AuthenticAMD unknown (AX 00700F01 CX 36D8220B DX 178BFBFF)
#l0: rtl8169: 1000Mbps port 0xE000 irq 4 ea 008cfad57b98
sbsetupahci: tweaking 7801 ccru 06 ccrp 01
#S/sdE: ahci: sata-II with 2 ports
#A0: hda mem feb60000 irq 4
#A0: codec #0, vendor 10ec0221, rev 00100003
usbohci: 0x1022 0x7807: port 0xfeb6d000 size 0x1000 irq 5
usbohci: 0x1022 0x7807: port 0xfeb6b000 size 0x1000 irq 5
usbehci: 0x1022 0x7808: port feb6c000 size 256 irq 10
usbehci: 0x1022 0x7808: port feb6a000 size 256 irq 10
usbxhci: 0x1022 0x7814: port feb68000 size 8192 irq 5
1467M memory: 493M kernel data, 973M user, 1598M swap
#l0: rtl8169: oui 0x732 phyno 1, macv = 0x4c000000 phyv = 0x0000
sdE1: LLBA 31,277,232 sectors
  SanDisk SDSA6MM-016G-1006 U221006 144226401249 [newdrive]
user[glenda]: stevie
secstore password: 
secstore

init: starting /bin/rc

Re: [9front] BUG: thinclient not booting with usbehci,usbohci

[cinap_lenrek]

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

Re: [9front] BUG: thinclient not booting with usbehci,usbohci

[stevie]

hi cinap!

I tested it on amd64 and 386. Skipping the EHCI controller leaves me with the same result as in my first mail.
Skipping OHCI boots on amd64 and 386 with:

	cpu0: spurious interrupt 39, last 0
	
and with no prompt on 386, but the box is not frozen.

On amd64 instead I get the same cpu0: message, but also get a prompt and the box boots fine.
Surprisingly for me this message gets not logged in /dev/kmesg, I can only see it on the "boot screen".

So I guess OHCI is the culprit? Why had *nousbohci= not the same effect?

Hope this helps.

-- stevie

Re: [9front] BUG: thinclient not booting with usbehci,usbohci

[cinap_lenrek]

> So I guess OHCI is the culprit? Why had *nousbohci= not the same effect?

I dont know. Maybe the reset procedure is wrong? Maybe SMM will inevitably
lock up the machine when we clear bus master on the device while it is still
ownerd by bios?

Maybe we can fix it by executing the usb handover protocols before pcireset()?

Until we have a solution, i'm going to revert the pcireset() call addition to
in pcicfginit() for now and add a comment describing the problem.

--
cinap