From owner-freebsd-current@freebsd.org Sun Mar 17 15:35:02 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 644DF153F63B for ; Sun, 17 Mar 2019 15:35:02 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD48384BAF for ; Sun, 17 Mar 2019 15:34:59 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 17 Mar 2019 15:34:50 +0000 Received: from [192.168.1.141] ([62.122.208.146]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 53B607AA-158C-49E1-A1F8-CBFB1B23578C.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 17 Mar 2019 15:34:50 +0000 Date: Sun, 17 Mar 2019 18:34:47 +0300 From: Greg V Subject: Re: Switching fb backend back to default To: Johannes Lundberg Cc: FreeBSD Current Message-Id: <1552836887.1930.0@unrelenting.technology> In-Reply-To: <95dfadc9-8341-b2a5-7b58-e94f46b5fa90@gmail.com> References: <95dfadc9-8341-b2a5-7b58-e94f46b5fa90@gmail.com> X-Mailer: geary/master~g7e6f39ed MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed DKIM-Signature: v=1; a=rsa-sha256; bh=THCLnOhjRKm+c/vxchjcxfDbJ0Y2zDWbQ5wBT/SfH+Y=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=Xbj8UAiiqHRq6LfYVHpGio6L3XWUoaWoY5UsN7sq3UOu2i3e+G/gYRJuFCdAgTS+f4cywSxRlnttxrU0/lbWibf9msA6CDlJmmCIddOqIqERIgICPvpmfS13RpyZrf84WK1S7CiNUsn4bONnt5qoFNzKw677qyvzhUWRhSHCsjM= X-Rspamd-Queue-Id: AD48384BAF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=Xbj8UAii; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-6.62 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; MX_GOOD(-0.01)[aspmx1.migadu.com,aspmx2.migadu.com]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.64)[ip: (-9.89), ipnet: 91.121.0.0/16(-4.15), asn: 16276(0.86), country: FR(-0.01)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(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: Sun, 17 Mar 2019 15:35:02 -0000 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.