Re: Panic from vesa_configure()

In message <56917D49.1000707_at_rice.edu>, Alan Cox writes:
> This is a multi-part message in MIME format.
> --------------080104010900060709060805
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
> 
> 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.gma
> il.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 repres
> ents?
> >>>>>>
> >>>>>> 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 s
> tuff
> >>> 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.

This fixes it.

pcib2: <ACPI PCI-PCI bridge> at device 15.0 on pci0
pci2: <ACPI PCI bus> on pcib2
vgapci0: <VGA-compatible display> mem 0xe8000000-0xefffffff,0xfddfe000-0xfdd
fffff irq 16 at device 0.0 on pci2
vgapci0: Boot video device
amdtemp0: <AMD CPU On-Die Thermal Sensors> on hostb3
acpi_tz0: <Thermal Zone> on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
orm0: <ISA Option ROM> at iomem 0xc0000-0xcc7ff on isa0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
powernow0: <PowerNow! K8> on cpu0
powernow1: <PowerNow! K8> on cpu1


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com> or <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.