From owner-freebsd-current@freebsd.org Sat Jan 9 22:38:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88C1AA6A3C0 for ; Sat, 9 Jan 2016 22:38:13 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62B651C8B; Sat, 9 Jan 2016 22:38:12 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.15.0.59/8.15.0.59) with SMTP id u09LZhef015312; Sat, 9 Jan 2016 15:36:10 -0600 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp1.rice.edu with ESMTP id 20avw505sf-1; Sat, 09 Jan 2016 15:36:10 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id BE56F4C01E7; Sat, 9 Jan 2016 15:36:09 -0600 (CST) Subject: Re: Panic from vesa_configure() To: Adrian Chadd , John Baldwin References: <201601070947.u079lWFk066644@slippy.cwsent.com> <6763716.RJFa7H2OmF@ralph.baldwin.cx> <56916800.7060109@rice.edu> Cc: freebsd-current , Cy Schubert , Jeremie Le Hen , Ryan Stone , =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= , "?Alan L. Cox" From: Alan Cox Message-ID: <56917D49.1000707@rice.edu> Date: Sat, 9 Jan 2016 15:36:09 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56916800.7060109@rice.edu> Content-Type: multipart/mixed; boundary="------------080104010900060709060805" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601090410 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 22:38:13 -0000 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 wrote: >>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote: >>>> In message >>> om> >>>> , Jeremie Le Hen writes: >>>>> On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd 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. --------------080104010900060709060805 Content-Type: text/plain; charset=UTF-8; name="vm_phys_alloc_contig2.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vm_phys_alloc_contig2.patch" SW5kZXg6IHZtL3ZtX3BoeXMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB2bS92bV9waHlzLmMJKHJl dmlzaW9uIDI5MzU4MCkKKysrIHZtL3ZtX3BoeXMuYwkod29ya2luZyBjb3B5KQpAQCAtMTM3 MiwxMiArMTM3MiwxMiBAQCByZXN0YXJ0ZG9tOgogCQlyZXR1cm4gKE5VTEwpOwogCX0KIAlt X3J1biA9IE5VTEw7Ci0JZm9yIChzZWdpbmQgPSAwOyBzZWdpbmQgPCB2bV9waHlzX25zZWdz OyBzZWdpbmQrKykgeworCWZvciAoc2VnaW5kID0gdm1fcGh5c19uc2VncyAtIDE7IHNlZ2lu ZCA+PSAwOyBzZWdpbmQtLSkgewogCQlzZWcgPSAmdm1fcGh5c19zZWdzW3NlZ2luZF07Ci0J CWlmIChzZWctPnN0YXJ0ID49IGhpZ2gpCisJCWlmIChzZWctPnN0YXJ0ID49IGhpZ2ggfHwg c2VnLT5kb21haW4gIT0gZG9tYWluKQorCQkJY29udGludWU7CisJCWlmIChsb3cgPj0gc2Vn LT5lbmQpCiAJCQlicmVhazsKLQkJaWYgKGxvdyA+PSBzZWctPmVuZCB8fCBzZWctPmRvbWFp biAhPSBkb21haW4pCi0JCQljb250aW51ZTsKIAkJaWYgKGxvdyA8PSBzZWctPnN0YXJ0KQog CQkJcGFfc3RhcnQgPSBzZWctPnN0YXJ0OwogCQllbHNlCg== --------------080104010900060709060805--