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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?452348D4.8070603>