Skip site navigation (1)Skip section navigation (2)
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>