Am 12.01.2018 um 00:03 schrieb Sean Bruno:
> https://reviews.freebsd.org/D13832 <--- test this update
>
> I'd like to get some feedback from AMD cpu users on this update. I've
> restructured and undone a few things that may have been keeping folks
> using this port from getting their runtime cpu
On Tue, 9 Jan 2018 21:23:54 +0300
"Andrey V. Elsukov" wrote:
> On 09.01.2018 12:28, O. Hartmann wrote:
> > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is
> > also an example:
> >
> > ipfw add deny ip from any to any out recv ed0 xmit ed1
> >
> > Can someone explain
On 4 January 2018 at 03:10, Michael Tuexen wrote:
>
> Not sure this helps: But we have seen this also after system panics
> when having soft update journaling enabled. Having soft update journaling
> disabled, we do not observed this after several panics.
> Just to be clear: The panics are not rel
On 1/11/2018 6:03 PM, Sean Bruno wrote:
> https://reviews.freebsd.org/D13832 <--- test this update
>
> I'd like to get some feedback from AMD cpu users on this update. I've
> restructured and undone a few things that may have been keeping folks
> using this port from getting their runtime cpu mi
On Fri, Jan 12, 2018 at 8:28 AM, Ed Maste wrote:
> On 4 January 2018 at 03:10, Michael Tuexen wrote:
> >
> > Not sure this helps: But we have seen this also after system panics
> > when having soft update journaling enabled. Having soft update journaling
> > disabled, we do not observed this aft
On 01/12/18 08:38, Mike Tancsa wrote:
> On 1/11/2018 6:03 PM, Sean Bruno wrote:
>> https://reviews.freebsd.org/D13832 <--- test this update
>>
>> I'd like to get some feedback from AMD cpu users on this update. I've
>> restructured and undone a few things that may have been keeping folks
>> usi
On 01/12/18 04:49, Rainer Hurling wrote:
> Am 12.01.2018 um 00:03 schrieb Sean Bruno:
>> https://reviews.freebsd.org/D13832 <--- test this update
>>
>> I'd like to get some feedback from AMD cpu users on this update. I've
>> restructured and undone a few things that may have been keeping folks
On 1/12/2018 11:58 AM, Sean Bruno wrote:
>>
>
> Probably, update your port of x86info. I pushed an update for this and
> it might work better for you.
Thanks, I tried it but still generates the error / warning. What does it
mean ? (CPU0: local APIC error 0x80)
It does however get rid of the "Un
On Fri, Jan 12, 2018 at 12:12:31PM -0500, Mike Tancsa wrote:
> On 1/12/2018 11:58 AM, Sean Bruno wrote:
> >>
> >
> > Probably, update your port of x86info. I pushed an update for this and
> > it might work better for you.
>
> Thanks, I tried it but still generates the error / warning. What does
On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard wrote:
>
> On 2018-Jan-8, at 1:15 AM, blubee blubeeme wrote:
>
> > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard
> wrote:
> >> [The involvement of sysutils/fusefs-simple-mtpfs
> >> and sysutils/fusefs-libs and multimedia/libmtp
> >> in order to use t
should_yield() compares thread::td_swvoltick to 'ticks' to determine
whether a thread is hogging and should yield. Since td_swvoltick
records 'ticks' /before/ the actual context switch, the calculation in
should_yield() includes any time that the thread was switched out. It
seems that should_yiel
On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote:
> should_yield() compares thread::td_swvoltick to 'ticks' to determine
> whether a thread is hogging and should yield. Since td_swvoltick
> records 'ticks' /before/ the actual context switch, the calculation in
> should_yield() includ
On 01/12/2018 13:36, Konstantin Belousov wrote:
> On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote:
>> should_yield() compares thread::td_swvoltick to 'ticks' to determine
>> whether a thread is hogging and should yield. Since td_swvoltick
>> records 'ticks' /before/ the actual conte
13 matches
Mail list logo
