Re: Issues with USB-C external monitors
On 01.12.2020 17:10, myfreeweb wrote:
> >> __snippet__
> >> res = drmModeGetResources(fd);
> >> for (int i = 0; i < res->count_connectors; ++i) {
> >> conn = drmModeGetConnector(fd, res->connectors[i]);
>
> Note: you can run graphics/drm_info instead of writing custom code.
Thanks for the tip.
> devd (really drm in the kernel) provides hotplug events (system DRM, type
> HOTPLUG).
> libudev-devd translates these to UD_ACTION_HOTPLUG.
> This works well with wlroots compositors at least.
>
> How xorg does this I have no idea, as I don't use xorg.
> 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.
> With UDEV it might work?
On current, for now I'm using the standard xorg-server from pkg, built
with UDEV according to [1], so apparently that is not working either. At
least in my case.
Will dig futher into it.
>
> >There is missing code in the kernel to handle USB-C PCI express
> >attach/detach. CC'ing Scott Long.
>
> Seems like this is about regular DisplayPort over USB-C (the USB side almost
> always handled in firmware for this on non-embedded computers).
> I don't think I've ever seen a *monitor* connecting over PCIe to an existing
> GPU ;)
> (in this case card0, the onboard vega)
Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
[1] https://www.freshports.org/x11-servers/xorg-server/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d/zpool runs before ada(4) attaches
Tue, 1 Dec. 2020 г. в 23:24, tech-lists : > > On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote: > >On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote: > >> > >> You can define these in /boot/loader.conf: > >> #kern.cam.boot_delay="1" # 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 > > kern.cam.boot_delay should still fix it because what is required is a delay > while the devices (all of the disks, zfs or not) get ready. Because root > has to happen before disks/zfs. > -- > J. I've reported a similar problem here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242189 some time ago. I just added the patch that solves it for me by delaying startup until CAM and USB scan is complete (that's overkill probably). -- Oleg Sidorkin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but xrandr shows it with ever increasing names "DP-3", "DP-4" etc. For now I've given up and use the T480's HDMI output instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d/zpool runs before ada(4) attaches
On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote: On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote: You can define these in /boot/loader.conf: #kern.cam.boot_delay="1" # 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 kern.cam.boot_delay should still fix it because what is required is a delay while the devices (all of the disks, zfs or not) get ready. Because root has to happen before disks/zfs. -- J. signature.asc Description: PGP signature
KLD zfs.ko: depends on kernel - not available or version mismatch
I’ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko. I updated to the latest current using svn up in /usr/src, then: make clean make buildworld kernel -j12 shutdown -r now boot to single user mode kldload zfs Which results in dmesg messages: KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type I can load the zfs kernel module from kernel.old just fine: ZFS filesystem version: 5 ZFS storage pool version: features support (5000) This happens with any kernel module I’ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW). I’ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail. I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help. Do I need to go back further to get into a usable state or is there something else I should be doing? Regards, Alban Hertroys -- There is always an exception to always. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
> On Dec 1, 2020, at 10:32 AM, Ali Abdallah wrote:
>
> On 01.12.2020 17:10, myfreeweb wrote:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
>>
>> Note: you can run graphics/drm_info instead of writing custom code.
>
> Thanks for the tip.
>
>> devd (really drm in the kernel) provides hotplug events (system DRM, type
>> HOTPLUG).
>> libudev-devd translates these to UD_ACTION_HOTPLUG.
>> This works well with wlroots compositors at least.
>>
>> How xorg does this I have no idea, as I don't use xorg.
>> 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.
>> With UDEV it might work?
>
> On current, for now I'm using the standard xorg-server from pkg, built
> with UDEV according to [1], so apparently that is not working either. At
> least in my case.
>
> Will dig futher into it.
>
>>
>>> There is missing code in the kernel to handle USB-C PCI express
>>> attach/detach. CC'ing Scott Long.
>>
>> Seems like this is about regular DisplayPort over USB-C (the USB side almost
>> always handled in firmware for this on non-embedded computers).
>> I don't think I've ever seen a *monitor* connecting over PCIe to an existing
>> GPU ;)
>> (in this case card0, the onboard vega)
>
> Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
>
> [1] https://www.freshports.org/x11-servers/xorg-server/
>
>
I have a work-in-progress to support Thunderbolt, but that’s not always the
same as just DisplayPort-over-USBC. If your connector has the Thunderbolt
logo, then it’s Thunderbolt, if it has the DP logo then it’s not. Even then,
the Thunderbolt component only controls enable/disable permissions and
bandwidth partitioning. The graphics chip and DRM code does the rest of the
work, and it sounds like the problems here are with those components.
Scott
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Issues with USB-C external monitors
Hello,
I have a T495 with a USB-C docking station with two external monitors,
running current to get the vega 10 amdgpu to work.
When the power is lost for on the USB-C dock, then the X server looses
all external monitors. They appear as disconnected after running xrandr
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...
I tried to debug the issue and I'm pretty sure that the X server on
FreeBSD is not reconfiguring the drm connectors automatically.
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.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes:
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: unknown
Now just running a simple libdrm code to rescan the connectors:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
After running the above code, the drm stack is somehow triggered to
re-read the DP-4.status, which appears now to be connected, but not
configured.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes: 1920x1080
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: connected
I didn't dig further to see if I can trigger the X server to re-scan drm
connectors and eventually remove those that vanished, and add newly
detected connectors. On Linux that seems to work automatically.
Any thoughts?
Regards,
Ali.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On December 1, 2020 2:00:55 PM UTC, Hans Petter Selasky
wrote:
>On 12/1/20 2:14 PM, Ali Abdallah wrote:
>> Hello,
>>
>> I have a T495 with a USB-C docking station with two external monitors,
>> running current to get the vega 10 amdgpu to work.
>>
>> When the power is lost for on the USB-C dock, then the X server looses
>> all external monitors. They appear as disconnected after running xrandr
>> 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...
>>
>> I tried to debug the issue and I'm pretty sure that the X server on
>> FreeBSD is not reconfiguring the drm connectors automatically.
>>
>> 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.
>>
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes:
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: unknown
>>
>> Now just running a simple libdrm code to rescan the connectors:
>>
>> __snippet__
>> res = drmModeGetResources(fd);
>> for (int i = 0; i < res->count_connectors; ++i) {
>> conn = drmModeGetConnector(fd, res->connectors[i]);
Note: you can run graphics/drm_info instead of writing custom code.
>> After running the above code, the drm stack is somehow triggered to
>> re-read the DP-4.status, which appears now to be connected, but not
>> configured.
>>
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes: 1920x1080
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: connected
>>
>> I didn't dig further to see if I can trigger the X server to re-scan drm
>> connectors and eventually remove those that vanished, and add newly
>> detected connectors. On Linux that seems to work automatically.
>>
>> Any thoughts?
devd (really drm in the kernel) provides hotplug events (system DRM, type
HOTPLUG).
libudev-devd translates these to UD_ACTION_HOTPLUG.
This works well with wlroots compositors at least.
How xorg does this I have no idea, as I don't use xorg.
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.
With UDEV it might work?
>There is missing code in the kernel to handle USB-C PCI express
>attach/detach. CC'ing Scott Long.
Seems like this is about regular DisplayPort over USB-C (the USB side almost
always handled in firmware for this on non-embedded computers).
I don't think I've ever seen a *monitor* connecting over PCIe to an existing
GPU ;)
(in this case card0, the onboard vega)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d/zpool runs before ada(4) attaches
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=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="1" # 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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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=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="1" # 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d/zpool runs before ada(4) attaches
Van: Harry Schmalzbauer
Datum: dinsdag, 1 december 2020 12:51
Aan: Ronald Klop , FreeBSD Current
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=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="1" # Delay (in ms) of root mount for CAM bus
#kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
Maybe that helps.
Ronald.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pam_zfs_key
Hi there! Is pam_zfs_key available in 13-CURRENT? I want to setup automatically loading zfs encryption keys for home datasets. Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On 12/1/20 2:14 PM, Ali Abdallah wrote:
Hello,
I have a T495 with a USB-C docking station with two external monitors,
running current to get the vega 10 amdgpu to work.
When the power is lost for on the USB-C dock, then the X server looses
all external monitors. They appear as disconnected after running xrandr
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...
I tried to debug the issue and I'm pretty sure that the X server on
FreeBSD is not reconfiguring the drm connectors automatically.
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.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes:
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: unknown
Now just running a simple libdrm code to rescan the connectors:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
After running the above code, the drm stack is somehow triggered to
re-read the DP-4.status, which appears now to be connected, but not
configured.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes: 1920x1080
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: connected
I didn't dig further to see if I can trigger the X server to re-scan drm
connectors and eventually remove those that vanished, and add newly
detected connectors. On Linux that seems to work automatically.
Any thoughts?
There is missing code in the kernel to handle USB-C PCI express
attach/detach. CC'ing Scott Long.
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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=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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rc.d/zpool runs before ada(4) attaches
Van: Harry Schmalzbauer Datum: dinsdag, 1 december 2020 09:43 Aan: freebsd-current@freebsd.org Onderwerp: rc.d/zpool runs before ada(4) attaches Hello, I'm playing with HEAD (post r364746, Merge OpenZFS support in to HEAD) on some of my non-out-of-box setups. 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=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. Regards, Ronald. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
rc.d/zpool runs before ada(4) attaches
Hello, I'm playing with HEAD (post r364746, Merge OpenZFS support in to HEAD) on some of my non-out-of-box setups. 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
