Re: link state changes take a "long" time to execute

On Thu, Jun 09, 2005 at 01:11:33AM +0100, Robert Watson wrote:
R> I'm running with task queue instrumentation on my notebook, and generate 
R> warnings when task queues take more than 1/10th of a second to execute. 
R> Normally the warnings fire only during the boot when tasks start being 
R> scheduled by ACPI, but the ACPI task queue thread isn't yet being 
R> scheduled to run because the scheduler hasn't been kicked off yet.  I saw 
R> one this afternoon as follows:
R> 
R> taskqueue_run: warning, queue time of 0.133978201 for context 0xc0687c90
					 ^^^^^^^^^^^

Is this seconds? A lot.

R> On my kernel, this function pointer resolves to:
R> 
R> c0687c90 t do_link_state_change
R> 
R> So it sounds like there's a substantial delay in the link change thread -- 
R> probably because another task takes a long time to execute, maybe 
R> blocking or delaying the task thread and preventing another task from 
R> running.  On this box, I'm running with an idle if_xl, and an in-use 
R> if_wi, which probably went into the associated state about when the 
R> message was printed.  Kernel source date is June 3.

Do you have vlans, ng_ether loaded, carp in kernel config, if_bridge?

Other idea may be that your syslogd was not running, and you have
serial console configured. In this case log(9) prints message to your
serial console, and then 0.13 seconds is sane time for this.

May be we should move log() from do_link_state_change() to
if_link_state_change()?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE