Timekeeping in stable/9

[Adrian Chadd]

.. if you have a _reproducable_ case for this, mav@ needs to see it ASAP.

The trouble is that mav@ isn't handed reproducable cases and thus can't
debug it.

If you can supply some kind of box that provides this as a reproducable
issue, we can get it fixed ASAP. Otherwise it's a case of "can't reproduce
in our environments, sorry."


Adrian

On 19 January 2012 13:09, Joe Holden <lists at rewt.org.uk> wrote:

> Joe Holden wrote:
>
>> Chuck Swiger wrote:
>>
>>> On Jan 19, 2012, at 12:18 PM, Joe Holden wrote:
>>>
>>>> Sounds like you were looking for commercial support, since unpaid
>>>>> volunteers don't have an obligation to promptly leap out and provide
>>>>> solutions within your ETA.
>>>>>
>>>> Not really, just an acknowledgement would be fine.  It is what it is,
>>>> everyday I try to argue in favour of the project, I still use it for myself
>>>> everywhere but increasingly things happen that just don't on other
>>>> volunteer projects... it's rather difficult to argue the case when they can
>>>> install Ubuntu or whatever nonsense distro is the current favourite and it
>>>> just works.  Just a bit more accurate info would solve it, if it doesn't do
>>>> X reliably, or Y has changed, note it.
>>>>
>>>
>>> You asked a question and got two or three responses back in a day.  You
>>> mentioned trying different timekeeping choices, but I don't recall seeing
>>> what your kern.timecounter sysctl values looked like; without that, folks
>>> are missing info that is likely to be relevant.
>>>
>>> Ah, well....
>>>
>>> Regards,
>>>
>> Yeah my gripe isn't with having no responses, the handful of people that
>> have responded have been helpful but ultimately no responses from anyone
>> involved.  Just a one liner saying "we changed the timecounter stuff in 9,
>> look at sysctl tree X" would have been more than sufficient, this sort of
>> thing should really be mentioned in the relnotes though...
>>
>> For the record though, setting kern.eventtimer.periodic to 1 fixes the
>> problem on all affected machines (returns my virtualbox guest to normality,
>> reduces the drift on physical machines to 8.2 figures).
>>
>> FWIW, I can't even see any notes relating to this in UPDATING either.
>>
> I should probably clarify here that some responses were received from the
> maintainers (eg: Qing for mpath) for a couple of bits of code but the wider
> issues weren't discussed further.  I'm not trying to say that no effort is
> made, but as a whole for the project to be comparable to the alternatives
> this sort of thing shouldn't happen.
>
>
>
> ______________________________**_________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable<http://lists.freebsd.org/mailman/listinfo/freebsd-stable>
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@**freebsd.org<freebsd-stable-unsubscribe at freebsd.org>
> "
>