From owner-freebsd-current@freebsd.org Tue Dec 1 15:47:09 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 056004AC817 for ; Tue, 1 Dec 2020 15:47:09 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Clmgc1Q0Wz4Rst; Tue, 1 Dec 2020 15:47:07 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 1 Dec 2020 16:47:04 +0100 (CET) From: Ronald Klop To: Ian Lepore Cc: FreeBSD Current Message-ID: <657848968.24.1606837624286@localhost> In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org> References: <1439301337.11.1606815206810@localhost> <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de> <286917313.21.1606836130991@localhost> <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org> Subject: Re: rc.d/zpool runs before ada(4) attaches MIME-Version: 1.0 X-Mailer: Realworks (536.33.bf126bdda67) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Clmgc1Q0Wz4Rst X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Dec 2020 15:47:09 -0000 Van: Ian Lepore Datum: dinsdag, 1 december 2020 16:34 Aan: Ronald Klop , FreeBSD Current Onderwerp: Re: rc.d/zpool runs before ada(4) attaches > > On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote: > > > > Van: Harry Schmalzbauer > > Datum: dinsdag, 1 december 2020 12:51 > > Aan: Ronald Klop , FreeBSD Current < > > freebsd-current@freebsd.org> > > Onderwerp: Re: rc.d/zpool runs before ada(4) attaches > > > > > > Am 01.12.2020 um 10:33 schrieb Ronald Klop: > > > : > > > : > > > : > > > > > One machine fails importing zpool because the correponding > > > > > vdevs >> (ada0-ada2) > > > > > are not available at the time rc.d/zpool runs. > > > > > > > > > > > > > > > Adhoc I'm not aware of any rc(8) vs. driver awareness. > > > > > Is there any? > > > > > > > > > > Suggestions how to fix else than 'sleep 1'? > > > > > > > > > > Thanks, > > > > > > > > > > -harry > > > > > > > > > > P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 > > > > > (Gen 10 >> plus MicroServer), zfsloader loads root_MFS kernel > > > > > module > > > > > > > > > > > > > > > > > There have been some changes to etc/rc.d/zpool in September. > > > > Do you have the latest version? Compare with: > > > > > https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool > > > > or > > > > > https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup > > > > > > > > > > > > > Otherwise it would be helpful for readers if you could post some > > > > logs > which indicate what is happening. > > > > /var/run/dmesg.boot or the output of "dmesg" > > > > Part of /var/log/messages > > > > Part of /var/log/console.log if it exists. > > > > > > > > > > Thanks, I'm on -current from view days ago. > > > The problem is that cam(4) is still probing devices, when > > > rc.d/zpool runs, since mount_root_from succeeded, because it is a > > > RAM disk, so succeeds independent of any real drive/controller > > > probing. > > > I can imagine of other seldom edgecases hitting the issue too. > > > > > > So my proposed patch, working for me, looks like this: > > > Index: libexec/rc/rc.d/zpool > > > =================================================================== > > > --- libexec/rc/rc.d/zpool (revision 368202) > > > +++ libexec/rc/rc.d/zpool (working copy) > > > @@ -18,8 +18,16 @@ > > > > > > zpool_start() > > > { > > > - local cachefile > > > + local cachefile n=0 camlist=`camcontrol devlist -v` > > > > > > + # Wait for cam(4) devices attaching, 4 times at max by > > > increasing > > > + # 1s each (10s max in total) > > > + while [ X"${camlist#*target*lun*probe}" != X"${camlist}" > > > ]; do > > > + [ $n -lt 4 ] || break > > > + sleep $((n+=1)) > > > + camlist=`camcontrol devlist -v` > > > + done > > > + > > > for cachefile in /etc/zfs/zpool.cache > > > /boot/zfs/zpool.cache; do > > > if [ -r $cachefile ]; then > > > zpool import -c $cachefile -a -N && break > > > > > > best, > > > -harry > > > > > > > > > > > > > You can define these in /boot/loader.conf: > > #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM > > bus > > #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI > > > > Maybe that helps. > > > > Ronald. > > > > Those settings control waiting before mounting root. Harry's problem > is that root is mounted quickly, before other drives are ready for zfs. > > The zpool script waits for 'disks'. It would be nice if the cam > subsystem had something like a sysctl it set to indicate when initial > probing for disks was done, then there could be an rc.d/camprobe script > with 'PROVIDE: disks' which waits for the probing to complete. > > -- Ian > > > > > Or a devd event "ada-arrived" which calls rc.d/zpool. It sounds a bit like we need systemd. :-) Ronald. From owner-freebsd-current@freebsd.org Tue Dec 1 17:10:23 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD1904AEC6A for ; Tue, 1 Dec 2020 17:10:23 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) (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 4ClpWg2hmRz4YST; Tue, 1 Dec 2020 17:10:22 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Tue, 01 Dec 2020 17:10:17 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: freebsd-current@freebsd.org, Hans Petter Selasky , Ali Abdallah , Scott Long Subject: Re: Issues with USB-C external monitors In-Reply-To: <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org> References: <20201201131430.ol7pzms24h743iwf@frix230> <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: greg@unrelenting.technology X-Rspamd-Queue-Id: 4ClpWg2hmRz4YST X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Dec 2020 17:10:23 -0000 On December 1, 2020 2:00:55 PM UTC, Hans Petter Selasky wrote: >On 12/1/20 2:14 PM, Ali Abdallah wrote: >> Hello, >>=20 >> I have a T495 with a USB-C docking station with two external monitors, >> running current to get the vega 10 amdgpu to work=2E >>=20 >> When the power is lost for on the USB-C dock, then the X server looses >> all external monitors=2E They appear as disconnected after running xran= dr >> and I cannot figure out a way to bring them back without killing my >> current session and start X again, but that is very annoying=2E=2E=2E >>=20 >> I tried to debug the issue and I'm pretty sure that the X server on >> FreeBSD is not reconfiguring the drm connectors automatically=2E >>=20 >> Let's say I have DP-4 as external connector, when the power is lost, >> DP-4 disappears, when the power is back, DP-4 re-appear again but in >> unknown status=2E >>=20 >> $ sysctl sys=2Eclass=2Edrm | grep DP-4 >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Emodes: >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Edpms: Off >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Eenabled: disabled >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Estatus: unknown >>=20 >> Now just running a simple libdrm code to rescan the connectors: >>=20 >> __snippet__ >> res =3D drmModeGetResources(fd); >> for (int i =3D 0; i < res->count_connectors; ++i) { >> conn =3D drmModeGetConnector(fd, res->connectors[i]); Note: you can run graphics/drm_info instead of writing custom code=2E >> After running the above code, the drm stack is somehow triggered to >> re-read the DP-4=2Estatus, which appears now to be connected, but not >> configured=2E >>=20 >> $ sysctl sys=2Eclass=2Edrm | grep DP-4 >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Emodes: 1920x1080 >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Edpms: Off >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Eenabled: disabled >> sys=2Eclass=2Edrm=2Ecard0-DP-4=2Estatus: connected >>=20 >> I didn't dig further to see if I can trigger the X server to re-scan dr= m >> connectors and eventually remove those that vanished, and add newly >> detected connectors=2E On Linux that seems to work automatically=2E >>=20 >> Any thoughts? devd (really drm in the kernel) provides hotplug events (system DRM, type = HOTPLUG)=2E libudev-devd translates these to UD_ACTION_HOTPLUG=2E This works well with wlroots compositors at least=2E How xorg does this I have no idea, as I don't use xorg=2E If your xorg is built with DEVD instead of UDEV option, it shouldn't work,= I don't recall anyone adding support for that there=2E With UDEV it might work? >There is missing code in the kernel to handle USB-C PCI express=20 >attach/detach=2E CC'ing Scott Long=2E Seems like this is about regular DisplayPort over USB-C (the USB side almo= st always handled in firmware for this on non-embedded computers)=2E I don't think I've ever seen a *monitor* connecting over PCIe to an existi= ng GPU ;) (in this case card0, the onboard vega)