On Mar 7, 2010, at 12:33 PM, Mikolaj Golub wrote:
> On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote:
>
>> Please check the results of the following command:
>>
>> % sysctl net.inet.tcp.timer_race
>> net.inet.tcp.timer_race: 0
>
> Are the results for FreeBSD7 look interesting for
On 28 Sep 2010, at 17:45, Sean Bruno wrote:
> Working on a dynamic version today. I'll spam it over to you for review
> later.
>
> I'm moving the percpu struct definitions outside of struct memory_type,
> allocating quantity kern.smp.maxcpus, removing the boundary checks based
> on MEMSTAT_MA
On 28 Sep 2010, at 19:40, Sean Bruno wrote:
>> If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
>
> I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some
> history here so I can understand why one is "better" than the other?
So, unlike maxcpus, mp_maxi
On 29 Sep 2010, at 12:49, John Baldwin wrote:
> On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote:
>>
>> On 28 Sep 2010, at 19:40, Sean Bruno wrote:
>>
>>>> If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
>>&
On 30 Sep 2010, at 19:19, Andriy Gapon wrote:
> http://people.freebsd.org/~avg/kern_shutdown-tunables.diff
>
> The above patch adds twin tunables for the following (R/W) sysctls:
> - debug.debugger_on_panic
> - debug.trace_on_panic
> - kern.sync_on_panic
>
> This seems useful to me, but I am no
On 13 Oct 2010, at 18:46, Ryan Stone wrote:
> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>> + /*
>> +* get and fill a header mbuf, then chain data as an
>> extended
>> +* mbuf.
>> +*/
>> + MGETHDR(m, M_DONTWAIT
On 14 Oct 2010, at 15:10, Attilio Rao wrote:
>> My concern is less about occasional lost dumps that destabilising the
>> dumping process: calls into the memory allocator can currently trigger a lot
>> of interesting behaviours, such as further calls back into the VM system,
>> which can then t
On 15 Oct 2010, at 20:39, Garrett Cooper wrote:
>But there are already some cases that aren't properly handled
> today in the ddb area dealing with dumping that aren't handled
> properly. Take for instance the following two scenarios:
> 1. Call doadump twice from the debugger.
> 2. Call doadu
On 15 Nov 2010, at 22:19, Alexander Best wrote:
> thanks for all your help. i've recently switched to chromium 6.0.472.63
> and so far my computer has been very stable.
>
> if i experience more lock ups i'll let you know and try to figure out a way to
> gain access to some more debugging data.
On 13 May 2010, at 10:21, Tom Evans wrote:
> I saw today that you've written a proof of concept MPM for apache in
> GCD [1] - are there any plans to port GCD to FreeBSD?
Hi Tom--
Actually, I also ported GCD to FreeBSD last year, and developed the MPM on
FreeBSD/GCD :-). It requires a post-8.0
On 25 May 2010, at 14:13, Nathan Whitehorn wrote:
>> I'm working on updating net/netatalk to version 2.1 (or 2.1.1 when that
>> comes out the next couple of days), and I'm wondering what state AppleTalk
>> support is in these days. Is anybody still using it, or would now be the
>> time to mak
On 25 May 2010, at 17:48, Julian Elischer wrote:
>> I'm working on updating net/netatalk to version 2.1 (or 2.1.1 when
>> that comes out the next couple of days), and I'm wondering what
>> state AppleTalk support is in these days. Is anybody still using
>> it, or would now be the time to make all
On 13 Jun 2016, at 12:09, Joel Dahl wrote:
>
>> On Mon, Jun 13, 2016 at 07:00:46AM -0400, Ngie Cooper (yaneurabeya) wrote:
>>
>>> On Jun 13, 2016, at 06:57, Joel Dahl wrote:
>>>
>>> Hi,
>>>
>>> I've just rebuilt and installed latest current on a machine here. I noticed
>>> the following messa
On 21 Dec 2011, at 15:31, John Baldwin wrote:
> On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote:
>> On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin wrote:
>>> Hmm, if these functions are expected to operate like 'write(2)' and are
>>> supposed to return the number of bytes written,
On 2 Dec 2012, at 14:21, Fbsd8 wrote:
>> I've now committed the build glue required to install the recently merged
>> Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and
>> sponsored by the FreeBSD Foundation. This allows individual hosts
>> generating audit trails to
On 2 Dec 2012, at 15:34, Ryan Stone wrote:
> On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson wrote:
>
> Just to follow up on this thread, since the question has come up a number of
> times. "mergemaser -p" should be run prior to installworld always, but most
> of the time will do very little.
My intuition (hope) is that 9.1 is past the point of no return on builds and so
that boat has been missed; however, my plan is to MFC the auditdistd user to
stable/8 and stable/9 after the 3-day MFC timeout. If Ken thinks builds have
yet to start on the final 9.1 image, however, then I'm happy t
On 26 Jun 2012, at 15:42, m...@freebsd.org wrote:
> While I understand the problems you allude to, the sysctl(8) binary
> can protect itself from them. IMO the biggest problem with sysctls
> not being files is that it makes no sense from the core UNIX
> philosophy that everything is a file. Soc
On 28 Sep 2013, at 19:32, Konstantin Belousov wrote:
>> It easy to reproduce. Just kldload mac_portacl and /etc/rc.d/syslogd restart
>
> This is due to priv_check_cred() call in mac_portacl.c:rules_check().
> The call causes recusion into the mac framework from the mac callback.
>
> Robert shou
On 1 May 2013, at 16:56, John Baldwin wrote:
> It looks like the ipi_hash_lock is locked (and udp_connect() locks it), so I
> think the offending code is somewhere else. Also, I can't find anything that
> removes an inp without hold the correct pcbinfo lock. Only thing I can think
> of is if t
On 1 May 2013, at 19:03, Glen Barber wrote:
>> I'll need to catch up on this thread later, but a few questions:
>>
>> Do we know if the application in question is multithreaded, and
>> if so, might it be attempting concurrent operations on this socket?
>
> I do not know if zabbix-agent is multi
On 2 May 2013, at 01:57, Glen Barber wrote:
> So, I am admittedly not too familiar with DDB. In fact, I just now
> realize the kernel is built without DDB...
DDB is a very powerful tool in that it's been custom-developed to help debug
common kernel panics. It lacks some of the flexibility, and
On 2 May 2013, at 11:42, Glen Barber wrote:
> Hmm. Perhaps it would be worthwhile for me to rebuild the current
> kernel with DDB support. It looks like the machine has panicked a few
> times over the last two weeks or so, but based on the timestamps of the
> crash dumps and nagios complaints,
On 16 Jun 2013, at 23:48, Kirk McKusick wrote:
>> I suppose it's safe to say further comment isn't forthcoming. So with
>> one vote for and one against (or at least questioning), I'll humbly
>> leave it up to myself to be the tie-breaker :-).
>>
>> Here's a proposed patch. I separate kmem access
On 24 Aug 2013, at 17:36, Alfred Perlstein wrote:
>> We should distinguish "lock contention" from "line contention". When
>> acquiring a rwlock on multiple CPUs concurrently, the cache lines used to
>> implement the lock are contended, as they must bounce between caches via the
>> cache cohere
On 6 Mar 2011, at 16:30, Jeremy Chadwick wrote:
2. Are you absolutely 100% sure the kernel you're using was built
with "options UFS_ACL" defined in it? Doing a "strings -a
/boot/kernel/kernel | grep UFS_ACL" should suffice.
>>>
>>> Yep, it does:
>>>
>>> % strings -a /b
On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
> I wonder if anybody uses kdb_stop_cpus with non-default value.
> If, yes, I am very interested to learn about your usecase for it.
The issue that prompted the sysctl was non-NMI IPIs being used to enter the
debugger or reboot following a core hangi
On 4 Jun 2011, at 09:22, Andriy Gapon wrote:
> on 03/06/2011 20:57 Robert N. M. Watson said the following:
>>
>> On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
>>
>>> I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I
>>> am very int
On 4 Jun 2011, at 15:30, Kristof Provost wrote:
> div_bind probably also needs to surround the call to in_pcbbind with
> INP_HASHW(UN)LOCK(...)
>
> I'm currently running 222680. I've only now seen the issue, but I've also
> just now activated INVARIANTS.
Hi Kristof:
Thanks for the detailed rep
29 matches
Mail list logo
