Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jan 2013 08:54:27 -0700
From:      Ian Lepore <ian@FreeBSD.org>
To:        Daniel Braniss <danny@cs.huji.ac.il>
Cc:        freebsd-stable@FreeBSD.org, Ronald Klop <ronald-freebsd8@klop.yi.org>
Subject:   Re: time issues and ZFS
Message-ID:  <1358783667.32417.434.camel@revolution.hippie.lan>
In-Reply-To: <E1TxJP2-000DS8-DJ@kabab.cs.huji.ac.il>
References:  <E1TxFcr-0006dx-MX@kabab.cs.huji.ac.il> <1358780588.32417.414.camel@revolution.hippie.lan> <E1TxJP2-000DS8-DJ@kabab.cs.huji.ac.il>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2013-01-21 at 17:35 +0200, Daniel Braniss wrote:
> ...
> > 
> > What's the output of sysctl kern.eventtimer?  
> 
> kern.eventtimer.periodic is 0
> 
> >                                              Does the bad behavior
> > change if you set kern.eventimer.periodic=1?
> > 
> 
> setting kern.eventtimer.timer=LAPIC
> instead of the default HPET made the missing cpu timers to appear:
> # vmstat -i                         
> interrupt                          total       rate
> irq3: uart1                         1695          0
> irq4: uart0                            5          0
> irq19: ehci0                        3875          0
> irq20: hpet0 uhci3               5495755       1135
> irq21: uhci2 ehci1                    29          0
> irq23: atapci0                        48          0
> cpu0:timer                          7063          1
> irq256: bce0                      117073         24
> irq260: mfi0                       51083         10
> irq261: mfi1                        3088          0
> cpu1:timer                           484          0
> cpu14:timer                           36          0
> cpu6:timer                           486          0
> cpu8:timer                            38          0
> cpu5:timer                            38          0
> cpu15:timer                           38          0
> cpu7:timer                            32          0
> cpu12:timer                           38          0
> cpu3:timer                            40          0
> cpu9:timer                            36          0
> cpu10:timer                           34          0
> cpu11:timer                           37          0
> cpu2:timer                            33          0
> cpu13:timer                           40          0
> cpu4:timer                            36          0
> Total                            5681160       1173
> 
> is this relevant?

I'll have to let someone who knows modern x86 hardware better comment on
the relative merits of hpet vs. lapic timers.  If it was using hpet in
one-shot mode, and changing it to hpet in periodic mode makes the
problem go away, that might be a clue that there's something wrong in
the hpet eventtimer start or interrupt routines.  

I wonder if a single missed interrupt in one-shot mode would bring an
eventtimer to a halt like that?  And if so, then what is it about
manually asking for the date that kicks it into running again?

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358783667.32417.434.camel>