From owner-freebsd-current@freebsd.org Tue Jan 30 20:28:13 2018 Return-Path: Delivered-To: freebsd-current@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 8FCF8EE0ADE for ; Tue, 30 Jan 2018 20:28:13 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 196F17F752 for ; Tue, 30 Jan 2018 20:28:13 +0000 (UTC) (envelope-from mqudsi@neosmart.net) Received: by mail-oi0-x230.google.com with SMTP id j15so5660255oii.5 for ; Tue, 30 Jan 2018 12:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neosmart.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=k1qqz4Zk829mcSCrs5s5NhU9OQ+OvzJPQXiX0YSYF5U=; b=xE8rZk9yq3BCDz5FdOPkHVc08vpyr3iZDPFX5K8sPHB2wUrt5oXa1n06F+VyB1b6Oj jyAp3d1lsXE+eRdy4SMoMHja2BZ48JeCek+bEEc9lPks1ssIi6nGDoXwttdtnOAO6OcG DUjaZ2yhjpBEe+e/Xw/4XubML/syz8uNkoPjQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k1qqz4Zk829mcSCrs5s5NhU9OQ+OvzJPQXiX0YSYF5U=; b=kiX4SkxWAfHFEyvGkY/LSpSwmUBSUgaUg//5QyPBnfYyUoUmPFsEaZUkd2vHfYZWX1 pGXvjM3/j2WGBnAFLpVj6xxOdZFqVTpJBENXobCsCxFt2WQSuwLAvxC/ji+NGjgjPPLI nNR8FFgYwIZWN+9M5c82cIaQ2wJ9wV2euBjdIeZemJpPRMcSz5YLTRVoxOMtuBNkvKlv ogPC44iIG1YkTIWrY3ep4wosABrTrrdAeu7kxBBzYoXmsGlXpp4msPeu3HYLtvsziOD1 KsfQQ8aLcvFvW4zgIpJx3c/ArNeM9OlhSsKOaXM/8fFjhn1Ol8WXgS/4ItiRw68R9/1D IYLQ== X-Gm-Message-State: AKwxytd4qJDxNfbuhX+xt3e78easww/hA1+hRkLhzh0GRA9qqkYWkj9s uiz2rYk+/aNP/ceAnUSHKykppWLL/h2Yj9JvtHAHeA== X-Google-Smtp-Source: AH8x226Y9rdKfQUzRhWrEdLY6iPVt56TrAgLlZyQCAB3T89DXkfcufWixm5eyAJGTZrIsJwcOJ1ww2tUGEau4SkdMSM= X-Received: by 10.202.195.144 with SMTP id t138mr5205095oif.311.1517344092066; Tue, 30 Jan 2018 12:28:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.61.230 with HTTP; Tue, 30 Jan 2018 12:27:51 -0800 (PST) From: Mahmoud Al-Qudsi Date: Tue, 30 Jan 2018 14:27:51 -0600 Message-ID: Subject: [PATCH] (validated against 50k+ i686 machines) for vmparam.h and vesa.c To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Tue, 30 Jan 2018 20:28:13 -0000 Hello list, NeoSmart Technologies has been using these patches to address issues in production for live CDs that are used by end users on their own (generic) hardware. We've validated the patches against well over 50k i686 machines, (not fleet machines, each is more or less unique/random), running a patched 10.x kernel over many years (you can see the original date in the attached patches). The first (and perhaps more important) addresses a common bug on x86 hardware, which results in the following error message combined with a panic at boot time: > Too many segments in the physical address map, giving up The second addresses bug kern/162373 which causes the framebuffer initialization to fail on certain graphics cards (AMD models seem particularly affected) with EINVAL, caused by incorrect range checks (which are actually prefaced with a "XXX: is this correct?" comment in the original source). We have our own framebuffer-based Xorg display driver (xf86-video-scfb, see [0]), so it was particularly important for us to have the framebuffer working correctly. I know some (extensive) changes have been made to the framebuffer with FreeBSD 11, so I'm not sure if the patch applies to code still in use or not; I have not taken the time to check under 12-CURRENT. [0]: https://github.com/neosmart/xf86-video-scfb Thanks, Mahmoud Al-Qudsi NeoSmart Technologies Patches follow. ------------------------------------------------------------------------------ >From 5829531f379d14939a4ec78e0d6647558cf4aa26 Mon Sep 17 00:00:00 2001 From: Mahmoud Al-Qudsi Date: Thu, 17 Apr 2014 14:09:59 -0500 Subject: [PATCH] Increased VM_PHSYSSEG_MAX on i386 Trying to fix an error "Too many segments in the physical address map, giving up" on boot that is seen on certain hardware configurations when booting the i386 GENERIC kernel. Previously attempted to work around this by setting hw.physmem to 3G, but that only resulted in a kernel segfault instead of the too many segments error. Using VM_PHYSSEG_MAX set to 31, as taken from the AMD64 configuration, initial testing seems to indicate this is OK for use on i386 as well. --- sys/i386/include/vmparam.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/i386/include/vmparam.h b/sys/i386/include/vmparam.h index 19cdd8e115eff..48e41a321d39b 100644 --- a/sys/i386/include/vmparam.h +++ b/sys/i386/include/vmparam.h @@ -74,7 +74,7 @@ * largest physical address that is accessible by ISA DMA is split * into two PHYSSEG entries. */ -#define VM_PHYSSEG_MAX 17 +#define VM_PHYSSEG_MAX 31 /* * Create two free page pools. Since the i386 kernel virtual address ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ >From b3af2d1ed4a63fe1a5d771ed3a052242250098d7 Mon Sep 17 00:00:00 2001 From: Mahmoud Al-Qudsi Date: Thu, 17 Apr 2014 12:17:44 -0500 Subject: [PATCH] Fixed incorrect range checks in mmap of framebuffer (kern/162373) Implemented a fix for incorrect/invalid range checks in the vesa framebuffer when attempting to mmap the framebuffer device. As described in kern/162373, the original code contains a bug and will incorrectly refuse to mmap at certain modes/resolutions because it thinks the mmap length is out-of-range when it isn't. Testing indicates that the revised framebuffer range check (mmap offset is less than the window buffer size instead of the old check that the offset is less than the window size minuse pagesize, which really makes no sense) is the correct way to go. --- sys/dev/fb/vesa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/dev/fb/vesa.c b/sys/dev/fb/vesa.c index 48067b6401fe6..c67b8f24e0d71 100644 --- a/sys/dev/fb/vesa.c +++ b/sys/dev/fb/vesa.c @@ -1631,7 +1631,7 @@ vesa_mmap(video_adapter_t *adp, vm_ooffset_t offset, vm_paddr_t *paddr, (adp->va_info.vi_flags & V_INFO_LINEAR) != 0) { /* va_window_size == va_buffer_size/vi_planes */ /* XXX: is this correct? */ - if (offset > adp->va_window_size - PAGE_SIZE) + if (offset >= adp->va_info.vi_buffer_size) return (-1); *paddr = adp->va_info.vi_buffer + offset; return (0); ------------------------------------------------------------------------------