From owner-freebsd-current@freebsd.org Mon Mar 18 19:28:31 2019 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 992F4154B72E for ; Mon, 18 Mar 2019 19:28:31 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [140.82.23.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12C4872714 for ; Mon, 18 Mar 2019 19:28:29 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from duke.gem.co (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 4cd739da TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Mon, 18 Mar 2019 12:28:22 -0700 (PDT) Subject: Re: Switching fb backend back to default To: Johannes Lundberg , Emmanuel Vadot Cc: FreeBSD Current , Greg V References: <95dfadc9-8341-b2a5-7b58-e94f46b5fa90@gmail.com> <1552836887.1930.0@unrelenting.technology> <6ea64218-2b6d-fc9a-01b5-ed07bd23c783@gmail.com> <20190317223531.b7334327a47f3579eaba98ee@bidouilliste.com> From: Pete Wright Message-ID: <8f3432cf-b02d-67cc-f284-6fb5c2192213@nomadlogic.org> Date: Mon, 18 Mar 2019 12:28:21 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 12C4872714 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 140.82.23.70 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-5.74 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mail.nomadlogic.org]; NEURAL_HAM_SHORT(-0.92)[-0.917,0]; IP_SCORE(-2.52)[ip: (-8.63), ipnet: 140.82.16.0/21(-4.32), asn: 20473(0.44), country: US(-0.07)]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[27.75.175.76.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:140.82.16.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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: Mon, 18 Mar 2019 19:28:31 -0000 On 3/17/19 2:50 PM, Johannes Lundberg wrote: > On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot wrote: > >> On Sun, 17 Mar 2019 16:32:43 +0000 >> Johannes Lundberg wrote: >> >>> On 3/17/19 3:34 PM, Greg V wrote: >>>> >>>> On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg >>>> wrote: >>>>> Hi >>>>> >>>>> I'm working on making i915kms unload properly. I've come to what I >> think >>>>> is the last issue. The drm driver unloads ok, the "efifb" backend is >>>>> restored (according to logs) and vt_efifb_init() is being called but >> the >>>>> screen (laptop built in display) stays black. The system seems >>>>> operational otherwise. If I load i915kms again in this state I get >> back >>>>> a visible (i915kms) framebuffer. >>>>> >>>>> Did we ever have this working so it's known to work? >>>> Recently on the linux kernel mailing list: >>>> >>>> http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html >>>> >>>>> Of course, once native drivers like i915 or radeon take over, such a >>>> framebuffer is toast... [6] >>>> >>>>> [6] >> linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() >>>>> linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() >>>> So it seems like efifb is not supposed to work after a driver has been >>>> loaded at least once. >>>> >>>> >>> Hmm, well the code is there to handle switching back to the boot time >>> fb. What I think is happening is that i915 powers off the displays at >>> unload and vt doesn't know how to power on (or that it should). >>> >> That and if the display pipeline is de-configured or the resolution >> changed you cannot reset it to the original state. >> Unloading drm modules is only useful for testing (and finding leaks). > > Yeah a normal user would never unload it. Since I mostly ssh to my test > machines I think I’m fine personally with losing the display while > unloading. > > Keyboard input still works though and at least it doesn’t crash anymore :) > that's awesome, so in theory we will be able to upgrade the drm-kmod and use the new driver without a reboot.  i like that as a hacker and end-user :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA