On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
On Thursday, February 5, 2015, Peter Wemm pe...@wemm.org wrote:
On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote:
On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote:
Sometime in the Dec 10th
On 5 February 2015 at 02:48, Luigi Rizzo ri...@iet.unipi.it wrote:
Rather than depending on a compiler option, wouldn't it be better/more
robust to change ticks to unsigned, which has specified wrapping behavior?
I believe there are cases other than ticks that rely on 2s complement
signed
On 5 Feb 2015, at 07:48, Luigi Rizzo ri...@iet.unipi.it wrote:
Rather than depending on a compiler option, wouldn't it be better/more
robust to change ticks to unsigned, which has specified wrapping behavior?
Especially if we want to extend support for external toolchains. gcc and clang
On 2/5/15 11:00 AM, Peter Wemm wrote:
On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote:
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
...
On Thursday, February 05, 2015 11:00:46 AM Peter Wemm wrote:
On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote:
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33
On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
...
It is fixed (in the proper meaning of the word, not like worked around,
covered by paper) by the patch at the end of the mail.
We already have a story
On Wed, Feb 4, 2015 at 6:15 PM, Peter Wemm pe...@wemm.org wrote:
--- kern/kern_clock.c 2014-12-01 15:42:21.707911656 -0800
+++ kern/kern_clock.c 2014-12-01 15:42:21.707911656 -0800
@@ -410,6 +415,11 @@
#ifdef SW_WATCHDOG
EVENTHANDLER_REGISTER(watchdog_list, watchdog_config, NULL,
On Thu, Feb 05, 2015 at 10:48:54AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
...
It is fixed (in the proper
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
...
It is fixed (in the proper meaning of the word, not like worked
around,
covered by
On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote:
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
...
It is fixed (in the proper
On 4 February 2015 at 09:29, Konstantin Belousov kostik...@gmail.com wrote:
So the issue is reproducable in 3 minutes after boot with the following
change in kern_clock.c:
volatile intticks = INT_MAX - (/*hz*/1000 * 3 * 60);
It is fixed (in the proper meaning of the word, not like worked
On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote:
On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote:
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
introduced to 11.x/head/-current.With HZ=1000 (the default for bare
metal, not for
On Thursday, February 5, 2015, Peter Wemm pe...@wemm.org wrote:
On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote:
On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote:
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has
been
introduced to
On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote:
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
introduced to 11.x/head/-current.With HZ=1000 (the default for bare
metal,
not for a vm); the clocks stop just after 24 days of uptime. This means
On Tuesday, February 3, 2015, Peter Wemm pe...@wemm.org wrote:
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
introduced to 11.x/head/-current.With HZ=1000 (the default for bare
metal,
not for a vm); the clocks stop just after 24 days of uptime.
This means
On Tue, 2015-02-03 at 13:33 -0800, Peter Wemm wrote:
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
introduced to 11.x/head/-current.With HZ=1000 (the default for bare
metal,
not for a vm); the clocks stop just after 24 days of uptime. This means
things like
Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
introduced to 11.x/head/-current.With HZ=1000 (the default for bare metal,
not for a vm); the clocks stop just after 24 days of uptime. This means
things like cron, sleep, timeouts etc stop working. TCP/IP won't time
17 matches
Mail list logo
