On 2016-Jul-8, at 12:23 AM, Mark Millard wrote --but with
a few []'d notes added:
> [Before the below cross build/update attempt I updated my amd64 from -r302331
> -> -r302412.]
>
> Summary: It appears that WITHOUT_META_MODE= still needs to be forced for
> cross compiles at least sometimes in
Hi,
That message just means a receive interrupt was handled whilst the NIC
was in reset, which is mostly fine.
Since you've reverted the ath driver directories without success, I'm
mostly out of simple ideas. I think you need to bisect the whole
kernel version until you find the commit that broke
* Wolfgang Zenker [160710 19:47]:
> * Adrian Chadd [160709 21:33]:
>> There weren't any changes in net80211 between those times, and ath(4)
>> only has some changes for locationing; nothing that should cause that
>> particular issue.
>> I'll go update to the latest -head on something with that N
Hi,
* Adrian Chadd [160709 21:33]:
> There weren't any changes in net80211 between those times, and ath(4)
> only has some changes for locationing; nothing that should cause that
> particular issue.
> I'll go update to the latest -head on something with that NIC and test
> it out some more.
> T
> On Jul 9, 2016, at 23:03, Mark Millard wrote:
>
> On 2016-Jul-9, at 8:53 PM, Ngie Cooper wrote:
>
>>> On Jul 9, 2016, at 18:52, bugzilla-nore...@freebsd.org wrote:
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953
>>>
>>> Mark Millard changed:
>>
>> I accidentally committe
On 10.07.2016 18:28, Andrey Chernov wrote:
> On 10.07.2016 18:13, Andrey Chernov wrote:
>> On 10.07.2016 18:12, Andrey Chernov wrote:
>>> On 10.07.2016 18:01, Slawa Olhovchenkov wrote:
On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote:
> On 10.07.2016 16:30, Slawa Olhovch
On 10.07.2016 18:13, Andrey Chernov wrote:
> On 10.07.2016 18:12, Andrey Chernov wrote:
>> On 10.07.2016 18:01, Slawa Olhovchenkov wrote:
>>> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote:
>>>
On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> I am surprised lack of support
On 10.07.2016 18:12, Andrey Chernov wrote:
> On 10.07.2016 18:01, Slawa Olhovchenkov wrote:
>> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote:
>>
>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
I am surprised lack of support GOST in openssl-base.
Can be this enabled bef
On 10.07.2016 18:01, Slawa Olhovchenkov wrote:
> On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote:
>
>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
>>> I am surprised lack of support GOST in openssl-base.
>>> Can be this enabled before 11.0 released?
>>
>> AFAIK openssl maintainer
On Sun, Jul 10, 2016 at 05:10:04PM +0300, Andrey Chernov wrote:
> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> > I am surprised lack of support GOST in openssl-base.
> > Can be this enabled before 11.0 released?
>
> AFAIK openssl maintainers says something like they can't support this
> code
Hi,
I have filed the PR in the subject [1], I'd like to ask if someone could
have a look, it's a bug I noticed on head which is also going to affect
11.0 if not corrected in time.
Since r270424, the output of certain ipfw show commands is mangled, due
to buffers not being cleaned between uses. Th
On Sun, 2016-07-10 at 13:13 +0200, Mateusz Guzik wrote:
> If the lock is contended, primitives like __mtx_lock_sleep will spin
> checking if the owner is running or the lock was freed. The problem
> is
> that once it is discovered that the lock is free, multiple CPUs are
> likely to try to do the a
On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
> I am surprised lack of support GOST in openssl-base.
> Can be this enabled before 11.0 released?
AFAIK openssl maintainers says something like they can't support this
code and it will become rotten shortly with new changes, so they drop it.
___
I am surprised lack of support GOST in openssl-base.
Can be this enabled before 11.0 released?
Subject: svn commit: r412619 - in head/dns: bind9-devel bind910 bind99
Author: mat
Date: Wed Apr 6 13:53:09 2016
New Revision: 412619
URL: https://svnweb.freebsd.org/changeset/ports/412619
Log:
Stop
On Sun, Jul 10, 2016 at 03:22:47PM +0300, Konstantin Belousov wrote:
> On Sun, Jul 10, 2016 at 01:13:26PM +0200, Mateusz Guzik wrote:
> > If the lock is contended, primitives like __mtx_lock_sleep will spin
> > checking if the owner is running or the lock was freed. The problem is
> > that once it
On Sun, Jul 10, 2016 at 01:13:26PM +0200, Mateusz Guzik wrote:
> If the lock is contended, primitives like __mtx_lock_sleep will spin
> checking if the owner is running or the lock was freed. The problem is
> that once it is discovered that the lock is free, multiple CPUs are
> likely to try to do
If the lock is contended, primitives like __mtx_lock_sleep will spin
checking if the owner is running or the lock was freed. The problem is
that once it is discovered that the lock is free, multiple CPUs are
likely to try to do the atomic op which will make it more costly for
everyone and throughpu
On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote:
> I can reproduce it on a clean 11.0-BETA1 VM.
>
>
> 2016-07-09 9:03 GMT+08:00 Huang Wen Hui :
>
> > For some reasons, r302324 seems not include in 11.0-ALPHA6?
> >
> > 2016-07-09 8:52 GMT+08:00 Huang Wen Hui :
> >
> >> Revert back r
I can reproduce it on a clean 11.0-BETA1 VM.
2016-07-09 9:03 GMT+08:00 Huang Wen Hui :
> For some reasons, r302324 seems not include in 11.0-ALPHA6?
>
> 2016-07-09 8:52 GMT+08:00 Huang Wen Hui :
>
>> Revert back r302324, Chinese locale problem is gone.
>>
>> Cheers
>> Huang Wen Hui
>>
>> 2016-07
19 matches
Mail list logo