Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Toomas Soome]

> On 28. Feb 2022, at 08:23, Michael Schuster  wrote:
> 
> Hi Toomas,
> 
> 
> On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  > wrote:
> 
> 
>> On 27. Feb 2022, at 23:36, Michael Schuster > > wrote:
>> 
>> Hi all,
>> 
>> I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 
>> 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD 
>> CURRENT from last week. 
>> 
> 
> [...] 
> 
> 
> UEFI or BIOS setup?
> 
> UEFI
>  
> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or 
> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will 
> cause the values list to be printed), or use loadfont command with your 
> custom font file (created with vtfontcvt).
> 
> I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm first 
> time. 
> 
> Many thanks!
> Michael

You are welcome.

rgds,
toomas

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Michael Schuster]

Hi Toomas,


On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  wrote:

>
>
> On 27. Feb 2022, at 23:36, Michael Schuster 
> wrote:
>
> Hi all,
>
> I'm trying to get a smaller font in my text-consoles (using vt) on my
> Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD
> CURRENT from last week.
>
> [...]


> UEFI or BIOS setup?
>

UEFI


> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or
> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will
> cause the values list to be printed), or use loadfont command with your
> custom font file (created with vtfontcvt).
>

I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm
first time.

Many thanks!
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/27/2022 3:58 pm, Mark Johnston wrote:

On Sun, Feb 27, 2022 at 01:16:44PM -0600, Larry Rosenman wrote:

On 02/26/2022 11:08 am, Larry Rosenman wrote:
> On 02/26/2022 10:57 am, Larry Rosenman wrote:
>> On 02/26/2022 10:37 am, Juraj Lutter wrote:
 On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
 I'm running this script:
 #!/bin/sh
 for i in $(zfs list -H | awk '{print $1}')
 do
   FS=$1
   FN=$(echo ${FS} | sed -e s@/@_@g)
   sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh
 l...@freenas.lerctr.org cat - \> $FN
 done



>>> I’d put, like:
>>>
>>> echo ${FS}
>>>
>>> before “sudo zfs send”, to get at least a bit of a clue on where it
>>> can get to.
>>>
>>> otis
>>>
>>>
>>> —
>>> Juraj Lutter
>>> o...@freebsd.org
>> I just looked at the destination to see where it died (it did!) and I
>> bectl destroy'd the
>> BE that crashed it, and am running a new scrub -- we'll see whether
>> that was sufficient.
>>
>> Thanks, all!
> Well, it was NOT sufficient More zfs export fun to come :(

I was able to export the rest of the datasets, and re-install 
14-CURRENT

from a recent snapshot, and restore the datasets I care about.

I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


That ioctl is DIOCGMEDIASIZE, i.e., something is asking /dev/mfi0, the
controller device node, about the size of a disk.  Presumably this is
the result of some kind of misconfiguration somewhere, and /dev/mfid0
was meant instead.



per advice from markj@ I deleted the /{etc,boot}/zfs/zpool.cache files, 
and this issue went

away.  Stale cache files which are no longer needed.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Mark Johnston]

On Sun, Feb 27, 2022 at 01:16:44PM -0600, Larry Rosenman wrote:
> On 02/26/2022 11:08 am, Larry Rosenman wrote:
> > On 02/26/2022 10:57 am, Larry Rosenman wrote:
> >> On 02/26/2022 10:37 am, Juraj Lutter wrote:
>  On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
>  I'm running this script:
>  #!/bin/sh
>  for i in $(zfs list -H | awk '{print $1}')
>  do
>    FS=$1
>    FN=$(echo ${FS} | sed -e s@/@_@g)
>    sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh 
>  l...@freenas.lerctr.org cat - \> $FN
>  done
>  
>  
>  
> >>> I’d put, like:
> >>> 
> >>> echo ${FS}
> >>> 
> >>> before “sudo zfs send”, to get at least a bit of a clue on where it 
> >>> can get to.
> >>> 
> >>> otis
> >>> 
> >>> 
> >>> —
> >>> Juraj Lutter
> >>> o...@freebsd.org
> >> I just looked at the destination to see where it died (it did!) and I
> >> bectl destroy'd the
> >> BE that crashed it, and am running a new scrub -- we'll see whether
> >> that was sufficient.
> >> 
> >> Thanks, all!
> > Well, it was NOT sufficient More zfs export fun to come :(
> 
> I was able to export the rest of the datasets, and re-install 14-CURRENT 
> from a recent snapshot, and restore the datasets I care about.
> 
> I'm now seeing:
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> pid 48 (zpool), jid 0, uid 0: exited on signal 6
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> mfi0: IOCTL 0x40086481 not handled
> pid 54 (zpool), jid 0, uid 0: exited on signal 6
> 
> On boot.  Ideas?

That ioctl is DIOCGMEDIASIZE, i.e., something is asking /dev/mfi0, the
controller device node, about the size of a disk.  Presumably this is
the result of some kind of misconfiguration somewhere, and /dev/mfid0
was meant instead.

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Toomas Soome]

> On 27. Feb 2022, at 23:36, Michael Schuster  wrote:
> 
> Hi all,
> 
> I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 
> 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD CURRENT 
> from last week. 
> 
> My research led me to believe that using vidcontrol would help me here, but 
> however I do try, "vidcontrol -i mode" prints nothing except the header line, 
> and other "vidcontrol" subcommands give me "Inappropriate ioctl for device".
> 
> I tried a few things
> - switched to sc via setting "kern.vty=sc" in /boot/loader.conf, this caused 
> a hang on reboot
> - setting "hw.vga.textmode" to 1
> - "kldload vesa"
> ... and probably a few other things I now forget, all to no effect - I still 
> get nothing.
> 
> I then performed an update from a freshly 'git pulled' source today (kernel, 
> world, drm-devel-kmod), a simple "vidcontrol" test still shows the same.
> 
> I know it can work because I had a smaller font before I re-installed over 
> the previous installation (which originally came from ghostbsd in Aug 2020), 
> so - I assume - it can't be rocket science :-)
> I'd appreciate further hints/pointers/RTFMs (though I've tried quite a few of 
> those).
> 

UEFI or BIOS setup? With UEFI, sc and hw.vga.textmode has no effect. With UEFI 
or BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will 
cause the values list to be printed), or use loadfont command with your custom 
font file (created with vtfontcvt).

rgds,
toomas

"vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Michael Schuster]

Hi all,

I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen
4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD
CURRENT from last week.

My research led me to believe that using vidcontrol would help me here, but
however I do try, "vidcontrol -i mode" prints nothing except the header
line, and other "vidcontrol" subcommands give me "Inappropriate ioctl for
device".

I tried a few things
- switched to sc via setting "kern.vty=sc" in /boot/loader.conf, this
caused a hang on reboot
- setting "hw.vga.textmode" to 1
- "kldload vesa"
... and probably a few other things I now forget, all to no effect - I
still get nothing.

I then performed an update from a freshly 'git pulled' source today
(kernel, world, drm-devel-kmod), a simple "vidcontrol" test still shows the
same.

I know it can work because I had a smaller font before I re-installed over
the previous installation (which originally came from ghostbsd in Aug
2020), so - I assume - it can't be rocket science :-)
I'd appreciate further hints/pointers/RTFMs (though I've tried quite a few
of those).

TIA
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: ZFS PANIC: HELP.

[Michael Butler]

On 2/27/22 16:09, Larry Rosenman wrote:

On 02/27/2022 3:03 pm, Michael Butler wrote:

[ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 
14-CURRENT from a recent snapshot, and restore the datasets I care 
about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and
mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended
up setting the debug flag for mrsas in /etc/sysctl.conf ..

dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael


I don't see it:
✖1 ❯ sysctl dev.mfi
dev.mfi.0.keep_deleted_volumes: 0
dev.mfi.0.delete_busy_volumes: 0
dev.mfi.0.%parent: pci3
dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 
subdevice=0x1f17 class=0x010400

dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0
dev.mfi.0.%driver: mfi
dev.mfi.0.%desc: Dell PERC H700 Integrated
dev.mfi.%parent:


 my brain-fade - you're right; it is only there and tunable in the 
mrsas driver.


My apologies :-(

Michael

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/27/2022 3:03 pm, Michael Butler wrote:

[ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 
14-CURRENT from a recent snapshot, and restore the datasets I care 
about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and
mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended
up setting the debug flag for mrsas in /etc/sysctl.conf ..

dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael


I don't see it:
✖1 ❯ sysctl dev.mfi
dev.mfi.0.keep_deleted_volumes: 0
dev.mfi.0.delete_busy_volumes: 0
dev.mfi.0.%parent: pci3
dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 
subdevice=0x1f17 class=0x010400

dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0
dev.mfi.0.%driver: mfi
dev.mfi.0.%desc: Dell PERC H700 Integrated
dev.mfi.%parent:

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: ZFS PANIC: HELP.

[Michael Butler]

 [ cc list trimmed ]

On 2/27/22 14:16, Larry Rosenman wrote:


I was able to export the rest of the datasets, and re-install 14-CURRENT 
from a recent snapshot, and restore the datasets I care about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?


These messages may or may not be related. I found both the mfi and mrsas 
drivers to be 'chatty' in this way - IOCTL complaints. I ended up 
setting the debug flag for mrsas in /etc/sysctl.conf ..


dev.mrsas.0.mrsas_debug=0

There's an equivalent for mfi

Michael

Re: ZFS PANIC: HELP.

[Larry Rosenman]

On 02/26/2022 11:08 am, Larry Rosenman wrote:

On 02/26/2022 10:57 am, Larry Rosenman wrote:

On 02/26/2022 10:37 am, Juraj Lutter wrote:

On 26 Feb 2022, at 03:03, Larry Rosenman  wrote:
I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=$1
  FN=$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh 
l...@freenas.lerctr.org cat - \> $FN

done




I’d put, like:

echo ${FS}

before “sudo zfs send”, to get at least a bit of a clue on where it 
can get to.


otis


—
Juraj Lutter
o...@freebsd.org

I just looked at the destination to see where it died (it did!) and I
bectl destroy'd the
BE that crashed it, and am running a new scrub -- we'll see whether
that was sufficient.

Thanks, all!

Well, it was NOT sufficient More zfs export fun to come :(


I was able to export the rest of the datasets, and re-install 14-CURRENT 
from a recent snapshot, and restore the datasets I care about.


I'm now seeing:
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 48 (zpool), jid 0, uid 0: exited on signal 6
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
mfi0: IOCTL 0x40086481 not handled
pid 54 (zpool), jid 0, uid 0: exited on signal 6

On boot.  Ideas?



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106