Subject: kern/10218: uhci logs 'host controller halted' after apm resume
To: None <gnats-bugs@gnats.netbsd.org>
From: John Hawkinson <jhawk@mit.edu>
List: netbsd-bugs
Date: 05/28/2000 20:28:24
>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: