Re: review request: loader: implement framebuffer console

[Gordon Bergling]

On Fri, Dec 04, 2020 at 11:23:41PM +0200, Toomas Soome wrote:
> > On 4. Dec 2020, at 23:03, Gordon Bergling  wrote:
> > Tested on a recent -CURRENT, no problems seen so far.
> > 
> > Is there a special src.conf setting that is necessary for a
> > complete build / test sequence.
> 
> No, except that the last update did change default for bios loader to text 
> and did add the knob to change that to gfx mode.
> 
> For test, the default mode should be readable and logo/brand images ok and 
> the console after boot usable as well. The resolution switch (gop or vbe) 
> should end up with usable screen as well, and when you enter menu, the boot 
> menu should be ok.
> 
> gop get/vbe get will list current mode, show screen.font will tell font size.
> 
> Currently it is known the 8-bit depth may have issues in some systems (bios, 
> UEFI only does have 32-bit depth).
> 
> thanks,
> toomas

I have set hw.vga.textmode="0" in the /boot/loader.conf and dmesg
reports "VT(efifb): resolution 1024x768" with the patch applied.
A kyua testrun was successfull.

Hope that helps.

--Gordon

> > On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> >> I have been working on proper framebuffer support on FreeBSD loader and 
> >> there is the current state: https://reviews.freebsd.org/D27420 
> >> 
> >> 
> >> All feedback is welcome, and especially if you can spare some time for 
> >> testing:)
> >> 
> >> thanks,
> >> toomas
___
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

[Harry Schmalzbauer]

Am 01.12.2020 um 16:34 schrieb Ian Lepore::
:
:
:

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


Until something described above is available, or anybody is aware of any 
other trick,
here's a tested workaround: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251610


It turned out that also swapon and dumpon suffer from early 
root_hold_wait() release.
For dumpon, cam(4) doesn't even start probing.  Luckily all target:LUNs 
are visible at that earliest stage in rc.d/dumpon.
So that's the point where I check if any real target is in state 
unattached (()) or probing ((aprobe)).
I don't know details of the involved vfs.root_mount_hold sysctl, but 
assume this is dead end currently...


Best regards,
-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

[Edward Tomasz Napierała]

On 1201T0834, 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.

I believe such a mechanism already exists, although it might be somewhat
misnamed: the vfs.root_mount_hold sysctl.  Some rc scripts use the
root_hold_wait() function, which uses the sysctl.  Perhaps the ZFS
scripts should do the same?

Note that this is somewhat more involved than just CAM - you also need
to wait for GEOM to settle.

___
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"