>Number:         10218
>Category:       kern
>Synopsis:       uhci logs 'host controller halted' after apm resume
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 28 20:29:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     John Hawkinson
>Release:        28 May 2000
>Organization:
MIT
>Environment:
	
System: NetBSD zorkmid.mit.edu 1.4Z NetBSD 1.4Z (ZORKMID-$Revision: 1.11 $) #139: Sun May 28 19:39:51 EDT 2000 jhawk@zorkmid.mit.edu:/usr/local/current-src/sys/arch/i386/compile/ZORKMID i386


>Description:
	When fxp0 is up (another PCI device on interrupt 9),
after an apm suspend/resume, uhci0 logs:

uhci_intr: suspended sts=0x20
uhci0: host controller halted

This is annoying. I presume that this is a not supposed to happen
in this case and that the uhci is getting a spurrious interrupt
when the fxp receives one, and is not handling it optimally.

This is on a Sony VAIO PCG-Z505HE.

>How-To-Repeat:
	dmesg output:
uhci0 at pci0 dev 7 function 2: Intel 82371AB USB Host Controller (PIIX4) (rev. 0x01)
uhci0: interrupting at irq 9
usb0 at uhci0: USB revision 1.0
fxp0 at pci0 dev 11 function 0: Intel i82557 Ethernet, rev 8
fxp0: interrupting at irq 9
fxp0: Ethernet address 08:00:46:06:00:6b, 10/100 Mb/s

	With apmdebug=0xfd and uhcidebug=0, suspending:
apmev: user suspend request
uhci_power: sc=0xc073f000, why=1 (was 0), cmd=0x1
uhci_run: setting run=0
uhci_run: done cmd=0x0 sts=0x20
uhci_power: cmd=0x9

	And then on resume:
apmev: resume system
uhci_intr: suspended sts=0x20
uhci0: host controller halted
uhci0 regs: cmd=0000, sts=0020, intr=0000, frnum=0000, flbase=fffff000, sof=0040, portsc1=0080, portsc2=0080
intrs=0
QH(0xc55e5fc0) at 00004fc0: hlink=00004fe2 elink=00000001
uhci_power: sc=0xc073f000, why=0 (was 1), cmd=0x0
uhci_run: setting run=1
uhci_run: done cmd=0x1 sts=0x0

>Fix:
	Perhaps this check in uhci_intr():
	status = UREAD2(sc, UHCI_STS);
	if (status == 0)	/* The interrupt was not for us. */
		return (0);

should mask out UHCI_STS_HCH (host controller halt)? I don't know
if that's correct. If not, perhaps the UHCI_STS_HCH case
should be much less noisy?
>Release-Note:
>Audit-Trail:
>Unformatted: