From owner-freebsd-current@freebsd.org Sat Jan 9 21:00:22 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 0BC6BA6A034 for ; Sat, 9 Jan 2016 21:00:22 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (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 DBB7B112C; Sat, 9 Jan 2016 21:00:21 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.15.0.59/8.15.0.59) with SMTP id u09K46F6015140; Sat, 9 Jan 2016 14:05:22 -0600 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp2.rice.edu with ESMTP id 20ax4k04wx-1; Sat, 09 Jan 2016 14:05:22 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh2.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 mh2.mail.rice.edu (Postfix) with ESMTPSA id 66B9C50013A; Sat, 9 Jan 2016 14:05:21 -0600 (CST) Subject: Re: Panic from vesa_configure() To: Adrian Chadd , John Baldwin References: <201601070947.u079lWFk066644@slippy.cwsent.com> <6763716.RJFa7H2OmF@ralph.baldwin.cx> 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 X-Enigmail-Draft-Status: N1110 Message-ID: <56916800.7060109@rice.edu> Date: Sat, 9 Jan 2016 14:05:20 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-1601090379 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 21:00:22 -0000 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 rep= resents? >>>>> >>>>> 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/ves= a.c:827). >>>> >>>> (kgdb) list *vga_init+0x65 >>>> 0xffffffff80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:140= 2). >>>> >>>> (kgdb) list *isavga_attach+0x92 >>>> 0xffffffff80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa= =2Ec: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 acp= i0 >>> 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 BIO= S 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 particul= ar, >> 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=3D0, high=3D4GB) 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. =20 > (The physmem code has explicit clue to do this if we wanted it to; it > has lowmem bits for allocation. I thought it was all working fine.) > > > -a >