Re: Panic from vesa_configure()

On 01/09/2016 14:05, Alan Cox wrote:
> On 01/09/2016 13:48, Adrian Chadd wrote:
>> On 9 January 2016 at 11:30, John Baldwin <jhb_at_freebsd.org> wrote:
>>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>>>> In message <CAGSa5y0QiKV9SgJYJ_mz3SnJGNjieHSvYP8nLjt9eWXo4RU6ww_at_mail.gmail.c
>>>> om>
>>>> , Jeremie Le Hen writes:
>>>>> On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd <adrian.chadd_at_gmail.com> wrote
>>>>> :
>>>>>> can you copy/paste the file:line that each of those stackframes represents?
>>>>>>
>>>>>> I may have an idea or two..
>>>>> Sure here we go:
>>>>>
>>>>> (kgdb) list *vesa_configure+0x270
>>>>> 0xffffffff80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c:827).
>>>>>
>>>>> (kgdb) list *vga_init+0x65
>>>>> 0xffffffff80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
>>>>>
>>>>> (kgdb) list *isavga_attach+0x92
>>>>> 0xffffffff80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:224).
>>>> Here is what I see. Only happens on real hardware (not VirtualBox VMs).
>>>>
>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>>>> uart0: console (9600,n,8,1)
>>>> acpi_alloc_wakeup_handler: can't alloc wake memory
>>> This is probably related to the same cause.  Both this and the x86 BIOS stuff
>>> need "low" memory (memory below 1MB).
>>>
>>> x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
>>> Perhaps the recent changes to contigmalloc() affect this?  In particular,
>>> try reverting r292469 to see if that fixes the issue.
>> Can't we just keep a pool of those pages around and not give them out
>> unless someone specifically asks for low memory?
> vm_phys.c already implements a "soft segregation" under which these
> pages are only allocated as a last resort, unless
> kmem_alloc_{attr,contig}() or contigmalloc() is called.
>
> What happened is that r292469 changed the order in which we pull from
> the free lists for kmem_alloc_{attr,contig}() and contigmalloc() so that
> a bunch of, for example, contigmalloc(low=0, high=4GB) calls, could
> potentially exhaust physical memory in the range [0, 1MB).  In other
> words, we're no longer getting the soft segregation among contigmalloc()
> calls.
>  

This patch should suffice to restore the soft segregation among
contigmalloc() calls.