From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Mon, 7 Aug 2006 22:40:16 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] timesync doubletime In-Reply-To: <6c264481f9b33ea17e28646b71d2565e@plan9.bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 9972badc-ead1-11e9-9d60-3106f5b1d025 this kernel has been running correctly for weeks. only when i tried running "aux/timesync -f /srv/sources". (i accidently had two running at once at one point.) did things go haywire. killing the timesync procs has not helped. so, without the benefit of timesync, have not seen any problems. i may be having a different or only sightly related problem. especially since i have neither a realtech, gbe, amd nor a multicore processor. just a "blue-light special" va linux dual coppermine. - erik On Mon Aug 7 21:13:17 CDT 2006, geoff@plan9.bell-labs.com wrote: > We've recently seen some slowness here that affects the clock. So far > I think it's only been seen on multiprocessor (multicore) AMD64 > systems with Realtek 8169 Gb Ethernet. Setting *ncpu=1 fixes the > problem at the cost of using only one processor. When we tried to add > debugging to the kernel to track this down, the problem vanished.