Date: Tue, 1 Dec 2020 16:47:04 +0100 (CET) From: Ronald Klop <ronald-lists@klop.ws> To: Ian Lepore <ian@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: rc.d/zpool runs before ada(4) attaches Message-ID: <657848968.24.1606837624286@localhost> In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org> References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de> <1439301337.11.1606815206810@localhost> <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de> <286917313.21.1606836130991@localhost> <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Van: Ian Lepore <ian@freebsd.org> Datum: dinsdag, 1 december 2020 16:34 Aan: Ronald Klop <ronald-lists@klop.ws>, FreeBSD Current <freebsd-current@freebsd.org> 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 <freebsd@omnilan.de> > > Datum: dinsdag, 1 december 2020 12:51 > > Aan: Ronald Klop <ronald-lists@klop.ws>, 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: <owner-freebsd-current@freebsd.org> 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 <freebsd-current@mailman.nyi.freebsd.org>; 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 <greg@unrelenting.technology> To: freebsd-current@freebsd.org, Hans Petter Selasky <hps@selasky.org>, Ali Abdallah <ali.abdallah@suse.com>, Scott Long <scottl@FreeBSD.org> 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: <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology> 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 <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=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 <hps@selasky=2Eorg= > 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?657848968.24.1606837624286>