.. 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 <li...@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@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-unsubscr...@freebsd.org> > " > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
