Subject: kern/26973: extremely long boot delay with no AC'97 codec connected
To: None <gnats-bugs@gnats.NetBSD.org>
From: Matthias Drochner <M.Drochner@fz-juelich.de>
Date: 09/16/2004 19:08:16
>Synopsis: extremely long boot delay with no AC'97 codec connected
>Arrival-Date: Thu Sep 16 17:09:00 UTC 2004
>Originator: Matthias Drochner
>Release: NetBSD 2.0G, 2.0_BETA
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
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 184.108.40.206.
2.0_BETA with ac97.c rev 220.127.116.11 suffers from the problem. Reverting
to rev. 18.104.22.168 makes it go away.
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
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
auich0: ac97: unknown (0x00000000) codec; no 3D stereo
Intel 82801DB/DBM AC97 Modem Controller (modem communications, revision 0x02)
pci0 dev 31 function 6 not configured
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
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.