Date: Tue, 03 Oct 2006 23:38:28 -0600 From: Scott Long <scottl@samsco.org> To: David G Lawrence <dg@dglawrence.com> Cc: freebsd-stable@freebsd.org, John Marshall <John.Marshall@riverwillow.com.au> Subject: Re: Watchdog Timeout - bge devices Message-ID: <452348D4.8070603@samsco.org> In-Reply-To: <20061004052453.GO17642@tnn.dglawrence.com> References: <9F7B653A50CF3D45A92C05401046239B0E0C27@rwsrv06.rw2.riverwillow.net.au> <45234418.7000205@samsco.org> <20061004052453.GO17642@tnn.dglawrence.com>
index | next in thread | previous in thread | raw e-mail
David G Lawrence wrote: >> Very interesting data point. I wonder if this accounts for some of the >> inconsistency in the reporting from others. In any case, SCHED_ULE is >> still considered to be highly experimental. Hopefully it will get some >> more attention in the near future to bring it closer to production >> quality. > > I'm not using SCHED_ULE on any of the machines that I'm seeing the > timeout problem with em and fxp devices. I suspect the problem has to do > with interrupt thread scheduling; maybe SCHED_ULE just somehow makes the > problem worse? > > -DG > Well, the two things that will block the scheduler are critical sections and spinlocks. The system will complain about spinlocks that are held too long, but you might need WITNESS and/or INVARIANTS enabled for it. Critical section debugging is almost non-existant; the only way to do it is to turn on KTR and then feed the output to schedgraph.py. This only works reliably for UP, though. Scotthome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?452348D4.8070603>