>Number:         26973
>Category:       kern
>Synopsis:       extremely long boot delay with no AC'97 codec connected
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 16 17:09:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Matthias Drochner
>Release:        NetBSD 2.0G, 2.0_BETA
>Organization:
	KFA Juelich
>Environment:
System: NetBSD zelz26 2.0G NetBSD 2.0G (ZELZ26) #56: Wed Sep 8 11:22:14 MEST 
2004 drochner@zelz26:/home/drochner/netbsd/sys/arch/i386/compile/ZELZ26 i386
Architecture: i386
Machine: i386
>Description:
	With sys/dev/ic/ac97.c rev 1.59 the code was changed to wait
until the codec(s) signal that they've reached power-up state on attach, and
after resume. This is right to do (required in the spec), but unfortunately
it waits for at least 10 minutes during boot if no codec is connected.
Such a hard hang for many minutes is unacceptable.
This change was pulled into the release branch as rev 1.52.2.2.
2.0_BETA with ac97.c rev 1.52.2.2 suffers from the problem. Reverting
to rev. 1.52.2.1 makes it go away.
>How-To-Repeat:
	Try to boot -current or the head of the 2.0 branch on hardware
without codec. My system looks that way:
NetBSD 2.0_BETA (GENERIC+EHCI) #7: Wed Sep 15 14:58:24 MEST 2004
        drochner@zelq08:/home/drochner/netbsd-2.0/sys/arch/i386/compile/GENERIC
+
EHCI
[...]
cpu0: Intel Pentium M (Banias) (686-class), 1697.17 MHz, id 0x695
[...]
pchb0: Intel E7501 MCH Host (rev. 0x01)
[...]
auich0 at pci0 dev 31 function 5: i82801DB/DBM (ICH4/ICH4M) AC-97 Audio
auich0: interrupting at irq 12
auich0: auich_reset_codec: time out
[long hang]
auich0: ac97: unknown (0x00000000) codec; no 3D stereo
Intel 82801DB/DBM AC97 Modem Controller (modem communications, revision 0x02) 
at
 pci0 dev 31 function 6 not configured

>Fix:
	At least in the newer "ICH" chips there is a bit to detect whether
the AC'97 bitclock is present at all. If it is not, there is no point
in trying any communication with codecs.
It might also make sense to stop codec attachment if just the initial
reset fails. This is also suggested by a comment in auich.c, but for
some reason it os not done that way. (There might be problems with
nonconformant hardware...)
The structure of the code is suboptimal obviously; while the Intel manual
strongly suggests to use shadow registers for almost all reads, the code
makes that they are not in effect except for restoration after resume.


>Release-Note:
>Audit-Trail:
>Unformatted: