svn commit: r226928 - head/sys/vm

[Sergey Kandaurov]

On 31 October 2011 21:13, Alan Cox <alc at rice.edu> wrote:
> On 10/31/2011 11:33, Sergey Kandaurov wrote:
>>
>> On 30 October 2011 09:06, Alan Cox<alc at freebsd.org>  wrote:
>>>
>>> Author: alc
>>> Date: Sun Oct 30 05:06:14 2011
>>> New Revision: 226928
>>> URL: http://svn.freebsd.org/changeset/base/226928
>>>
>>> Log:
>>>  Eliminate vm_phys_bootstrap_alloc().  It was a failed attempt at
>>>  eliminating duplicated code in the various pmap implementations.
>>>
>>>  Micro-optimize vm_phys_free_pages().
>>>
>>>  Introduce vm_phys_free_contig().  It is fast routine for freeing an
>>>  arbitrary number of physically contiguous pages.  In particular, it
>>>  doesn't require the number of pages to be a power of two.
>>>
>>>  Use "u_long" instead of "unsigned long".
>>>
>>>  Bruce Evans (bde@) has convinced me that the "boundary" parameters
>>>  to kmem_alloc_contig(), vm_phys_alloc_contig(), and
>>>  vm_reserv_reclaim_contig() should be of type "vm_paddr_t" and not
>>>  "u_long".  Make this change.
>>
>> Hello.
>>
>> After updating to this revision I constantly get random mtrash_ctor()
>> assertions. [most often during make installkernel, otherwise idle.]
>>
>> Below is one of them (previous memory consumers in panicstr differ).
>>
>> Memory modified after free 0xfffffe0002700800(120) val=0 @
>> 0xfffffe0002700800
>> panic: Most recently used by proc-args
>>
>> cpuid = 1
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at 0xffffffff802e009a = db_trace_self_wrapper+0x2a
>> kdb_backtrace() at 0xffffffff80486f17 = kdb_backtrace+0x37
>> panic() at 0xffffffff8044f87e = panic+0x2ee
>> mtrash_ctor() at 0xffffffff8068c904 = mtrash_ctor+0x84
>> uma_zalloc_arg() at 0xffffffff8068c16c = uma_zalloc_arg+0x2dc
>> malloc() at 0xffffffff8043abd6 = malloc+0xc6
>> pargs_alloc() at 0xffffffff804425d3 = pargs_alloc+0x23
>> kern_execve() at 0xffffffff8041cb47 = kern_execve+0x1277
>> sys_execve() at 0xffffffff8041ce6d = sys_execve+0x3d
>> amd64_syscall() at 0xffffffff806c6319 = amd64_syscall+0x299
>> Xfast_syscall() at 0xffffffff806b16b7 = Xfast_syscall+0xf7
>> --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800d4cbec, rsp =
>> 0x7fffffffd1a8, rbp = 0x8014124a0 ---
>>
>>
>
> I've not experienced anything like this, and I can't really see a direct
> connection between the above crash and the change.  So, the only thing that
> I can suggest is reverting one piece of the change at a time.  Please try
> this first:
>

 I'm sorry.
It appears that was due to regression in my local changes which triggered
coinciding with this revision. I just reproduced it without your change.
Sorry for noise.

-- 
wbr,
pluknet