Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Jul 2013 14:58:43 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Tugrul Erdogan <h.tugrul.erdogan@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: panic: kmem_map too small at heavy packet traffic
Message-ID:  <CAJ-Vmo=7YD3Bcz6RiEtpbxQ%2BrgnZzqyQk1WquPDxEJ2VD%2BpLcQ@mail.gmail.com>
In-Reply-To: <CA%2Bwhn7TCCEgO6mZDubriQFtgK_JfGvGC67hZKzUC3cBQOivPCw@mail.gmail.com>
References:  <CA%2Bwhn7StUGJH014tKx7TpeUomFO3RB9Sqv3DgTRNAgaM66kaPA@mail.gmail.com> <CAJ-VmokNHQ-9ZW80RvQFsYZFmD6A3KjFqS60xDWc0=KgX4v_qQ@mail.gmail.com> <CA%2Bwhn7TCCEgO6mZDubriQFtgK_JfGvGC67hZKzUC3cBQOivPCw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Cool, what's the PR number?

It sounds like something is odd. Email -current with the PR details
(number, how you reproduce it, etc) and let's see if we can get one of
the VM/UMA gurus to look into it.

Thanks,



-adrian

On 27 July 2013 00:26, Tugrul Erdogan <h.tugrul.erdogan@gmail.com> wrote:
> I have just pilled a PR.
>
> The negative written value is directly malloc's size parameter (in fact
> after some page size alignment enlargements operation). This parameter has
> been defined as "unsigned long" but printing with "%ld" as signed long. So
> if the size is very very big (more than 2^63 at amd64), the signed printing
> can remark the first bit of size as sign bit then write the - sign. But I
> think the size can not be so big, for this reason you are right, there must
> be a
> problem (the size parameter can come as negative or the enlargement
> functions can destroy the size parameter).
>
>
> On Sat, Jul 27, 2013 at 12:21 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>>
>> Hi
>>
>> Have you filed a PR? This should get fixed.
>>
>> Also, being -ve is a problem. Is the value really negative? Is it
>> wrapping badly?
>>
>>
>>
>> -adrian
>>
>> On 25 July 2013 07:57, Tugrul Erdogan <h.tugrul.erdogan@gmail.com> wrote:
>> > howdy all,
>> >
>> > At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB
>> > ram. I am taking
>> >
>> > "panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total
>> > allocated"
>> >
>> > message with configuration below:
>> >
>> > [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size
>> > vm.kmem_size_scale
>> > vm.kmem_size_min: 0
>> > vm.kmem_size_max: 329853485875
>> > vm.kmem_size: 16686845952
>> > vm.kmem_size_scale: 1
>> > [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem
>> > hw.physmem: 17151787008
>> > hw.usermem: 8282652672
>> > hw.realmem: 18253611008
>> > [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages
>> > hw.pagesize: 4096
>> > hw.pagesizes: 4096 2097152 0
>> > hw.availpages: 4187448
>> >
>> >
>> > When I compare vmstat and netstat output of boot time result and
>> > subsequent result, the major difference are seemed at:
>> >
>> > pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128
>> >
>> > and after the panic at the core dump file the major vmstat difference
>> > is:
>> >
>> > temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115
>> > 16,32,64,128,2
>> >
>> > When I explore the source code of kernel (at vm_kern.c and vm_map.c), I
>> > see
>> > that the panic can occur with the cases at below:
>> >
>> > * negative malloc size parameter
>> >
>> > * longer than free buffer respect to kmem_map min_offset and max_offset
>> > values
>> >
>> > * try to allocate when the root entry of map is the rightmost entry of
>> > map
>> >
>> > * try to allocate bigger than map's max_free value
>> >
>> > I think the panic occurs at mbuf creation process when calling malloc()
>> > as
>> > a result of couldn't be able to allocate memory; but I don't understand
>> > why
>> > one of this panic case activating? The memory is almost empty but the
>> > device is saying kmem_map small when using about 0.5GB memory purely.
>> > How
>> > can i solve this panic problem?
>> >
>> > Thank you all for your time.
>> >
>> > -- Best Wishes,
>> >
>> > Tugrul Erdogan
>> > _______________________________________________
>> > freebsd-hackers@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> > To unsubscribe, send any mail to
>> > "freebsd-hackers-unsubscribe@freebsd.org"
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=7YD3Bcz6RiEtpbxQ%2BrgnZzqyQk1WquPDxEJ2VD%2BpLcQ>