The following reply was made to PR kern/30505; it has been noted by GNATS.

From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/30505 fxp locks out audio for half a second
Date: Sun, 24 Jul 2005 23:25:30 +0200

 The half a second delay is caused by the MII function
 mii_phy_auto() that does a busy-wait for completition
 if called with the waitfor flag.
 
 Normally this is only noticed when the interface is
 (re-)configured and this happens on a process context
 that does not lock out other interrupts (like audio).
 
 It may also happen after an error on interrupt context
 to flush output buffers before the interface is
 reinitialized.
 
 A change in dev/ic/i82557.c version 1.85 however
 causes a regular reset of the fxp interface every
 16 seconds to work around a possible receiver-lockup
 (probably some chip bug).
 
 Note that the receiver lockup never occured on that
 system and the workaround is not necessary here.
 The test for possibly buggy hardware must be
 improved since the 16 second reset is never a
 good idea and affects almost everything in the
 system (e.g. firewire).
 
 The problem behind is worse, the mii_phy_auto()
 function may busy-wait. It does also call tsleep()
 for some devices (which therefore must operate
 on process context or use their own kernel-threads).
 It can also defer processing to a callout routine
 (mii_phy_auto_timeout). And the tlphy driver does
 abuse the busy-wait to add further actions to
 follow the autonegotiation.
 
 One simple possible solution is to defer autonegotiation
 processing always to a kernel-thread that may
 tsleep().
 
 I would also suggest to make mii_phy_auto() always work
 asynchronously and to add another function that waits for
 autonegotiation to complete or time out and that is
 limited to a process or kernel-thread context.
 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."