From owner-freebsd-bugs@freebsd.org Tue Jun 5 14:46:21 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AE6AFE5F34 for ; Tue, 5 Jun 2018 14:46:21 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8877C865 for ; Tue, 5 Jun 2018 14:46:20 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mailman.ysv.freebsd.org (Postfix) id 5A2FAFE5F1D; Tue, 5 Jun 2018 14:46:20 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3162FE5F0C for ; Tue, 5 Jun 2018 14:46:19 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2252C7C85A for ; Tue, 5 Jun 2018 14:46:19 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mail-oi0-x22f.google.com with SMTP id l22-v6so2316968oib.4 for ; Tue, 05 Jun 2018 07:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neosmart.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5/QulgiHU/1kHXK6KgIe4I4UvHRwVCXnWkSFezMbGMM=; b=u7vk5lnDfyeuotopmpRbRZTyJQdYF97nWvXRsj/+soLEERgJRGSwSb3foteMEBi10U N4xpbysYOTUVfUjQlxQuM2HGzg61Lk883DBrnIsLmQb//PJnF82YwlS48YKFECe7TV8z 3P2vfDmh+iQ2XlP/aU87hlB9zrHPNSsqiiYcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5/QulgiHU/1kHXK6KgIe4I4UvHRwVCXnWkSFezMbGMM=; b=fb4JTnBMxiu7iITEJtV+jj54Qu62p7Wp2ywKVB88QwAGUa9Q56HfFF48gXnscPsIX0 BnJ00578+hvxB2y4fGkwGwb9FXYFMWfpN1JGSTeen+UDHHmD1aHWMeZNdJjvPD9K13zu vBVmCrBBHhBSZoqr6cdxb9ljMHuVni6FFaCSzV1fviy6zuxb0iFNKMOj9ppt2VHcdtoM yDpJzBkRQ9xSX2VKccm+JZ34azLF/7w9qraXeGD3yx7rzZoBO+fzQaOlpVJ1dLlGhzoi GUB+a51fzZeHS7VVYiUeLaEZPmVRkNGMxTOBz4w3DfCvwUPbmYzb9mJnZ05Z8nzZftpX +R0Q== X-Gm-Message-State: APt69E2ejiX+6gOCOuXTmul0UwerbL1TVqjHRGHasCmYmLokmiHbiTdN vA+cb84hw1Tu98kz6pezXlPSeTJdL2JJDzAKru79NA== X-Google-Smtp-Source: ADUXVKKeMwAOBSzF9yApH53PtSgqAN2X56xDFi/GctxpbguC0LnKOWn5QyAObNwtOoDMLQDq1ILsD/krsCQWu7EFn5E= X-Received: by 2002:aca:2d56:: with SMTP id t83-v6mr15463924oit.208.1528209978321; Tue, 05 Jun 2018 07:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:e8f:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 07:45:57 -0700 (PDT) In-Reply-To: <20180605175705.Q2604@besplex.bde.org> References: <20180605175705.Q2604@besplex.bde.org> From: Mahmoud Al-Qudsi Date: Tue, 5 Jun 2018 09:45:57 -0500 Message-ID: Subject: Re: [Bug 228755] libvgl under syscons causes system reboot (via SDL 1.2) To: Bruce Evans Cc: bugs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:46:21 -0000 On Tue, Jun 5, 2018 at 4:00 AM, Bruce Evans wrote: > After fixing libvgl to use MAP_SHARED, libvgl and the demo work much the > same as in FreeBSD-5. Modes up to 1280x1024x8 work in both. Fancier > modes fail in both. The only interesting difference is that mmap() fails > for VGA mode 257 in -current both works in FreeBSD-5. The same (FreeBSD-5) > libvgl and demo program apparently calculates a too-large frame buffer size > in -current only, and mmapping this fails. mmap() also fails for > 1920x1080x8. Getting this size wrong in the driver is more likely to > cause a reboot than failing. Yes, I ran into that bug when attempting to pin down the underlying problem in libvgl directly instead of using SDL; when I manually called VGLInit with a mode that didn't directly error out (with a return code greater than -7), the memory allocation would fail and VGLInit() would return -7. (The buffer size should be printed with LIBVGL_DEBUG _before_ the attempted memory allocation currently on line 258 of libvgl/main.c, imho). But, as you say, that doesn't cause the system to reboot, obviously. Mahmoud Al-Qudsi NeoSmart Technologies