Re: Some alpha problems in current

[christos%astron.com@localhost (Christos Zoulas)]

In article <20080208.091951.116646721.jarle%uninett.no@localhost>,
Jarle Greipsland  <jarle%uninett.no@localhost> wrote:
>"Michael L. Hitch" <mhitch%NetBSD.org@localhost> writes:
>> On Wed, 6 Feb 2008, Jarle Greipsland wrote:
>> >>    The machine survived 16 hours (until 04:55), at which point it paniced
>> >> with "fpsave ipi didn't".  CPU 1 was hung and I couldn't get a backtrace
>> >> from it.  This would also explain the panic - CPU 0 is waiting for the
>> >> other CPU to process the fpusave ipi, but it's probably spinning somewhere
>> >> and unable to process the ipi.  This type of panic used to be fairly
>> >> frequent before, but I was able to track down the deadlock at the time and
>> >> that particular problem was fixed.  It looks like it may be back again.
>> > This is all very similar to the problems I reported in
>> > port-alpha/37712.
>> 
>>    I'd say it's the same problem.
>> 
>>    I know what's happening, but not why or how to fix it.
>Probably unrelated, but the timekeeping on my CS20 is also quite
>wacky.  Shortly after booting a 4.99.53 -current kernel, the NTP
>time synchronization can no longer keep the time in sync with the
>NTP servers used.  Also, I am quite puzzled by the following
>output:
># while true; do date; sleep 1; done
>Thu Feb  7 13:09:54 CET 2008
>Thu Feb  7 13:09:55 CET 2008
>Thu Feb  7 13:09:55 CET 2008
>Thu Feb  7 13:09:56 CET 2008
>Thu Feb  7 13:09:56 CET 2008
>Thu Feb  7 13:09:57 CET 2008
>Thu Feb  7 13:09:57 CET 2008
>Thu Feb  7 13:09:58 CET 2008
>Thu Feb  7 13:09:58 CET 2008
>Thu Feb  7 13:09:59 CET 2008
>Thu Feb  7 13:09:59 CET 2008
>Thu Feb  7 13:10:00 CET 2008
>Thu Feb  7 13:10:00 CET 2008
>Thu Feb  7 13:10:01 CET 2008
>Thu Feb  7 13:10:01 CET 2008
>
>The wall time seems to advance slower by a factor of 2 compared
>to whatever timer the sleep call uses.
>
>This was all with the time settings the kernel arrived on by
>itself:
>kern.timecounter.choice = PCC(q=1000, f=1666149600 Hz)
>clockinterrupt(q=0, f=1024 Hz) dummy(q=-1000000, f=1000000 Hz)
>kern.timecounter.hardware = PCC
>kern.timecounter.timestepwarnings = 0
>
>I then switched the timecounter source to clockinterrupt, and
>immediately the time keeping started behaving sanely again:
># while true; do date; sleep 1; done
>Thu Feb  7 13:10:42 CET 2008
>Thu Feb  7 13:10:43 CET 2008
>Thu Feb  7 13:10:44 CET 2008
>Thu Feb  7 13:10:45 CET 2008
>
>I notice that the kernel thinks that the frequency of the PCC is
>1666149600, while I seem to recall that the marketing blurb for
>the CS20 claimed that the 21264 CPUs were clocked at 833MHz.  Of
>course there may be some clock doubling going on somewhere, but
>the factor of 2 made me a bit curious.

Yes, time is completely broken even with 4.99.48 :-)

christos