Re: revision not displayed in a2440348eed7

[Yuri]

KIRIYAMA Kazuhiko wrote:
> Hi, list
> 
> I updated to a2440348eed7, but could not display revision:
> 
> admin@tbedfc:~ % uname -a
> FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 00:15:10 JST 
> 2023 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> admin@tbedfc:~ % 
> 
> Why ???

Are you using WITH_REPRODUCIBLE_BUILD?

sed in CURRENT fails in textproc/jq

[Yuri]

Either something has changed in sed(1) in CURRENT, or sed just fails 
during the configure stage of textproc/jq:


sed: No error: 0
checking for sys/cygwin.h... eval: ${+...}: Bad substitution


See the log: 
https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/peb032111a352_s9c80d66ec1/logs/jq-1.7.log




Yuri

Re: Jail compile error on CURRENT?

[Yuri]

James Gritton wrote:
> On 2023-08-07 13:29, Dimitry Andric wrote:
>> On 7 Aug 2023, at 04:50, Yoshihiro Ota  wrote:
>>>
>>> Am I the only one seeing this error?
>>> I'm on 12.4-RELEASE amd64 and building CURRENT as of now.
>>>
>>> jaillex.c:2228:43: error: unused parameter 'yyscanner'
>>> [-Werror,-Wunused-parameter]
>>> void *yyalloc (yy_size_t  size , yyscan_t yyscanner)
>>>  ^
>>> jaillex.c:2233:58: error: unused parameter 'yyscanner'
>>> [-Werror,-Wunused-parameter]
>>> void *yyrealloc  (void * ptr, yy_size_t  size , yyscan_t yyscanner)
>>>     ^
>>> jaillex.c:2245:36: error: unused parameter 'yyscanner'
>>> [-Werror,-Wunused-parameter]
>>> void yyfree (void * ptr , yyscan_t yyscanner)
>>>   ^
>>> 6 errors generated.
>>> *** [jaillex.o] Error code 1
>>>
>>
>> It seems you are not crazy. :) I can reproduce the error, and I think it
>> might be caused by:
>>
>> https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5
>>
>> However, as to why this does not result in an error (or even a warning)
>> on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got
>> updated...
> 
> That is indeed the culprit.  Fortunately, it builds from 13.2-RELEASE,
> so building CURRENT from 12 can be done in two steps.  I hate to be the
> reason the update doesn't work directly, but the include capability I
> added to jail(8) requires re-entrant lex, which apparently managed to
> work around the error in 13.  They reason it doesn't give a warning BTW
> is these two lines that lex adds:
> 
>     struct yyguts_t * yyg = (struct yyguts_t*)yyscanner;
>     (void)yyg;
> 
> That makes yyscanner officially "used" even though its value is never
> actually read.  I suspect the version of lex in 12.4-RELEASE doesn't
> have one or both of those lines.
> 
> Perhaps you could add such lines to the offending functions yourself,
> and continue the make.  Or maybe build (and install) lex on its own
> first; by the time you see this error, there should already be a newer
> version of lex you could pop into place.
> 
> There's probably something I should do to make this work better, or
> perhaps some note I should put into UPDATING before 14.0 is released.

Or there is already a recipe for bootstrapping lex in Makefile.inc1,
though for somewhat older versions; possibly it could be updated for < 13?

.if ${BOOTSTRAPPING} < 133

panic: Segment size is not aligned (smartpqi related)

[Yuri]

Hi,

I'm getting the panic below trying to install latest current snapshot
(20230720) on HPE Proliant 380 Gen10.

There don't seem to be any recent changes to smartpqi driver itself so
it's likely something else changed as this HBA didn't have *this*
specific problem previously on this system.  The panic happens after
selecting the disk for ZFS pool and confirming that its contents are
going to be destroyed.  What's interesting, doing `gpart destroy -F da0`
from installer shell didn't trigger this.

I have not tried to bisect this yet as it's very time consuming
(uploading iso images to remote site takes hours) and hoping someone
could point out the problem.

panic: Segment size is not aligned
cpuid = 53
KDB: stack backtrace
vpanic()
panic()
bounce_bus_dmamap_load_ma() at bounce_bus_dmamap_load_ma+0x402
bus_dmamap_load_mem() at bus_dmamap_load_mem+034a
bus_dmamap_load_ccb() at bus_dmamap_load_ccb+05d
pqi_map_request() at pqi_map_request+0x54
smartpqi_cam_action() at smartpqi_cam_action+0xca1
xpt_run_devq() at xpt_run_devq+0x2e9
xpt_action_default() at xpt_action_default+0x3fd
dastart() at dastart+0x327
xpt_run_allocq() at xpt_run_allocq+0x9f
dastrategy() at dastrategy+0x6d
g_disk_start() at g_disk_start+0x36f
g_io_request() at 0x2c2
g_io_request() at 0x2c2
g_io_request() at 0x2c2
g_dev_strategy() at g_dev_strategy+0x155
physio() at physio+0x4a1
devfs_write_f() at devfs_write_f+0xf3
dofilewrite(() at dofilewrite+0x82
sys_write() at sys_write+0xc2
amd64_syscall() at amd64_syscall+0x138
fast_syscall_common() at fast_syscall_common+0xf8
--- syscall (4, FreeBSD ELF64, write), rip = 0x2899740792ba, rsp =
0x289971621568, rbp = 0x289971621c00 ---

Re: HST time zone

[Yuri]

David Cornejo wrote:
> On Tue, Jul 25, 2023 at 11:01 AM Dimitry Andric  > wrote:
> 
> On 25 Jul 2023, at 22:26, David Cornejo  > wrote:
> >
> > One thing that has bothered me for a long time is that the
> Pacific/Honolulu timezone is found under the America -- North and
> South/United States of America/Hawaii in tzsetup. Politics of
> Hawaiian Sovereignty aside, every other system I regularly install
> uses Pacific/Honolulu as it is in the official tzdb.

tzsetup is (more or less) following the logic of the original tzselect
script from tzcode.

> > Is there any reason why a patch to change to match the standard
> would be refused?

What kind of standard and what exactly needs to be patched?

> Which version of FreeBSD are you using? On my 14-CURRENT box, Hawaii
> is actually found in *two* locations in tzsetup:
> 
> * America -- North and South -> United States of America -> Hawaii
> * Pacific Ocean -> United States of America -> Hawaii

Using tzsetup compiled with -DVERBOSE shows that both options install
Pacific/Honolulu.

> 
> 
> It just seems that the "standard" is Pacific/Honolulu and we are
> different - in the IANA tz db, there is only mention of
> Pacific/Honolulu. While I'm not saying they're correct, every Linux dist
> I've tried uses it. I have a mixed shop, and every difference is a
> potential problem.

We are not really different as the timezone file selected is indeed
Pacific/Honolulu.  What is the exact difference with linux dists?

> I doubt that this affects many people, so consistency would not seem a
> hardship.
>
> So that would serve all sides? :)
> 
> As far as I can see, the menu is dynamically generated from
> /usr/share/zoneinfo/zone1970.tab, which has:
> 
> US      +211825-1575130 Pacific/Honolulu        Hawaii
> 
> and seems to be up-to-date with regards to the IANA tz files.

Right, tzsetup only processes what's there in zone1970.tab.

Re: problems on new -current install with pkg/ssl

[Yuri]

void wrote:
> Hi,
> 
> On a fresh 14-current install (main-n263444-653738e895ba) I try to use
> pkg for anything and this error
> happens:
> 
> # pkg install doas
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from
> pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, please wait...
> Verifying signature with trusted certificate
> pkg.freebsd.org.2013102301... done
> Installing pkg-1.19.2...
> Newer FreeBSD version for package pkg:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400092
> - running kernel: 1400090
> Ignore the mismatch and continue? [y/N]: y
> Extracting pkg-1.19.2: 100%
> ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"
> 
> How can I fix?

That's the case where you should NOT ignore the "Newer FreeBSD version
for package pkg" warning and update the base OS first, see "OpenSSL 3.0
is in the tree" message on this list.

motivation for iconv versions of mbrtocXX functions

[Yuri]

(also CC'ed current@ in case anyone else knows the answer)

Hi Ed,

Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272293, I
noticed that non-iconv implementations of mbrtoc16/32 work correctly for
the provided test case, and before digging deeper into the issue with
iconv ones, I would like the initial motivation here, i.e. do you
remember what issues exactly did you see without iconv?

commit 49111f0092c9eff1bc03d95c7ca6275dc677b273
Author: Ed Schouten 
Date:   Mon Jun 3 17:17:56 2013 +

Add libiconv based versions of *c16*() and *c32*().

I initially thought wchar_t was locale independent, but this seems to be
only the case on Linux. This means that we cannot depend on the *wc*()
routines to implement *c16*() and *c32*(). Instead, use the Citrus
libiconv that is part of libc.

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Yuri]

Yuri wrote:
> Michael Gmelin wrote:
>> Hi,
>>
>> I didn't dig into this yet.
>>
>> After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
>> get this on boot:
>>
>>   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
>>
>> (booting stops at this point)
>>
>> Seems like the boot loader is missing this recently added feature.
> 
> Are you sure it was June 1's?  I saw this problem on:
> 
> FreeBSD-14.0-CURRENT-amd64-20230427-60167184abd5-262599-disc1.iso
> 
> ...but it was fixed since (for me, at least):
> 
> FreeBSD-14.0-CURRENT-amd64-20230504-4194bbb34c60-262746-disc1.iso

Trying to remember, I think I hit "send" too soon, it was 20230504
actually with a problem, and I think I had to use the previous one to
install.  Sorry for the noise.

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Yuri]

Michael Gmelin wrote:
> Hi,
> 
> I didn't dig into this yet.
> 
> After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
> get this on boot:
> 
>   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> 
> (booting stops at this point)
> 
> Seems like the boot loader is missing this recently added feature.

Are you sure it was June 1's?  I saw this problem on:

FreeBSD-14.0-CURRENT-amd64-20230427-60167184abd5-262599-disc1.iso

...but it was fixed since (for me, at least):

FreeBSD-14.0-CURRENT-amd64-20230504-4194bbb34c60-262746-disc1.iso

Re: Surprise null root password

[Yuri]

bob prohaska wrote:
> On Fri, May 26, 2023 at 07:48:04PM +0100, Ben Laurie wrote:
>> -T on ls will give you full time resolution...
>>
> More's the wonder:
> root@www:/usr/src # ls -lT /etc/*p*wd*
> -rw---  1 root  wheel   2099 May 10 17:20:33 2023 /etc/master.passwd
> -rw-r--r--  1 root  wheel   1831 May 10 17:20:33 2023 /etc/passwd
> -rw-r--r--  1 root  wheel  40960 May 10 17:20:33 2023 /etc/pwd.db
> -rw---  1 root  wheel  40960 May 10 17:20:33 2023 /etc/spwd.db
> 
> For sake of clarity, /etc/master.passwd's root line is
> root::0:0::0:0:Charlie &:/root:/bin/sh
> while /etc/passwd's root line is
> root:*:0:0:Charlie &:/root:/bin/sh
> 
> I just noticed a second host (Pi3) which is similarly affected.
> It completed a build/install cycle on May 25, uname -a yields
> FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #46 
> main-n263122-57a3a161a92f: Thu May 25 21:25:57 PDT 2023 
> b...@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> 
> On this host I get
> root@www:/usr/src # ls -lT /etc/*p*wd*
> -rw---  1 root  wheel   1796 Nov 12 16:00:03 2022 /etc/master.passwd
> -rw-r--r--  1 root  wheel   2430 Oct  1 19:40:22 2020 /etc/passwd
> -rw-r--r--  1 root  wheel  40960 Oct  1 19:40:22 2020 /etc/pwd.db
> -rw---  1 root  wheel  40960 Oct  1 19:40:22 2020 /etc/spwd.db
> (at least the dates make more sense)
> 
> The root line in /etc/master.passwd is
> root::0:0::0:0:Charlie &:/root:/bin/sh
> 
> I didn't catch any null password reports in the security emails,
> most likely through lack of attention. As with the first case,
> passwords seem to work normally (null rejected, normal accepted).

The question is how you update the configuration files,
mergemaster/etcupdate/something else?

Re: Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

[Yuri]

David Wolfskill wrote:
> This is from an in-place source update from main-n263073-634a770a5e16 to
> main-n263112-ad513b4dba3e:
> 
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
> Building 
> /common/S4/obj/usr/src/amd64.amd64/usr.bin/mkimg/tests/img-1x1-4096-mbr.vhdx
> Building /common/S4/obj/usr/src/amd64.amd64/cddl/usr.sbin/zfsd/zfsd.full
> /usr/src/usr.sbin/bhyvectl/bhyvectl.c:2389:24: error: incompatible pointer 
> types passing 'struct vm_exit *' to parameter of type 'struct vm_run *' 
> [-Werror,-Wincompatible-pointer-types]
> error = vm_run(vcpu, );
>  ^~~
> /common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/vmmapi.h:158:46: note: 
> passing argument to parameter 'vmrun' here
> int vm_run(struct vcpu *vcpu, struct vm_run *vmrun);
>  ^
> 1 error generated.
> 
> 
> Given that yesterday's update was uneventful, and that
> src/usr.sbin/bhyvectl/bhyvectl.c has not changed in several days,
> I'm guessing that perhaps a recent change to a header, possibly
> involving vmexit, may be at issue here.

https://lists.freebsd.org/archives/dev-commits-src-all/2023-May/026954.html

Re: FreeBSD wont boot on AMD Ryzen 9 7950X

[Yuri]

Mike Jakubik wrote:
> Hello,
> 
> Thanks for the info. At least I know it's not specific to my parts. Is
> there any knob one can turn in the BIOS to enable/disable this feature?
> iirc UART is old school serial ports? Wonder if removing UART support
> from the kernel would be a workaround.

Try the following from the loader prompt (option 3 from the beastie menu):

set hint.uart.0.disabled=1
set hint.uart.1.disabled=1
boot

Re: photo/video on tty console with the new VT/framebuffer

[Yuri]

Tomek CEDRO wrote:
> On Fri, May 19, 2023 at 1:44 PM Alastair Hogge wrote:
>> On 2023-05-19 11:30, Tomek CEDRO wrote:
>>> On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote:
 As long as those packages support DRMKMS and does your GPU, you can to a
 degree. I noticed video works for mpv and games/sdl, tho, I cannot get
 input working. I tried the Doom 3 port, and watched movies with mpv all
 from the vty just a couple of months ago.
>>>
>>> Yeah, I have input problem too, maybe worth investigating as this is
>>> really neat feature to have gfx with no Xorg :-)
>>
>> It is worth investigating! In a long dead ago project, the input,
>> events, and displays were all integrated into the vty and mux'd from
>> there. The kernel provides evdev devices now, and there is a library,
>> tho I do not know how to get vt(4) to integrate with evdev, or if the
>> library is the way to do it? Any other ideas?
> 
> Hey there Niclas :-) Do you know how to enable input devices
> (keyboard/mouse) in the console graphical applications? Is it
> possible? :-)
Wayland something?

Re: Delay in 14.0-RELEASE cycle and blocking items

[Yuri]

Yuri wrote:
> Michael Osipov wrote:
>> Am 2023-05-15 um 22:19 schrieb Yuri:
>>> Michael Osipov wrote:
>>>> Am 2023-05-15 um 21:37 schrieb Glen Barber:
>>>>> On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
>>>>>> Glen,
>>>>>>
>>>>>> do you see any chance to get this finally merged:
>>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
>>>>>>
>>>>>> It seriously affects people (in enterprises) behind a proxy, curl will
>>>>>> be a problem and py-requests is already a serious problem.
>>>>>>
>>>>>
>>>>> I have bumped the bug, and pinged sef@ and cc'd re@ as a result.
>>>>>
>>>>> I do not see a problem with it, as long as it is a proper fix.
>>>>
>>>> Thank you! I have verified the patch back then, will happily re-verify
>>>> if requested to.
>>>
>>> I just tried this (without patching):
>>>
>>> $ cat ~/.login_conf
>>> me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
>>> $ env | egrep 'FOO|BAR|BAZ'
>>> BAZ=foo,bar
>>> BAR=baz
>>> FOO=bar
>>
>> Not in /etc/login.conf:
>>> $ grep NO /etc/login.conf
>>>     :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4
>>> -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
>>> $ env | grep NO
>>> NO_PROXY='localhost
> 
> Weird, works for me running main-n262913-bee3d4bf8ed5:
> 
> $ grep NO_PROXY /etc/login.conf
> :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\
> $ env | grep NO_PROXY
> NO_PROXY=localhost,*.siemens.net

Oh, the fix is in there:

commit f32db406504ece1b28f43dc816736e081fe22826
Author: Sean Eric Fagan 
Date:   Sat Jan 14 10:37:31 2023 -0800

Allow a comma-separated list in login class capabilities,
by adding a version of strcspn that allows quoting.

So what exactly are we talking about here? :-)

Re: Delay in 14.0-RELEASE cycle and blocking items

[Yuri]

Michael Osipov wrote:
> Am 2023-05-15 um 22:19 schrieb Yuri:
>> Michael Osipov wrote:
>>> Am 2023-05-15 um 21:37 schrieb Glen Barber:
>>>> On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
>>>>> Glen,
>>>>>
>>>>> do you see any chance to get this finally merged:
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
>>>>>
>>>>> It seriously affects people (in enterprises) behind a proxy, curl will
>>>>> be a problem and py-requests is already a serious problem.
>>>>>
>>>>
>>>> I have bumped the bug, and pinged sef@ and cc'd re@ as a result.
>>>>
>>>> I do not see a problem with it, as long as it is a proper fix.
>>>
>>> Thank you! I have verified the patch back then, will happily re-verify
>>> if requested to.
>>
>> I just tried this (without patching):
>>
>> $ cat ~/.login_conf
>> me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
>> $ env | egrep 'FOO|BAR|BAZ'
>> BAZ=foo,bar
>> BAR=baz
>> FOO=bar
> 
> Not in /etc/login.conf:
>> $ grep NO /etc/login.conf
>>     :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4
>> -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
>> $ env | grep NO
>> NO_PROXY='localhost

Weird, works for me running main-n262913-bee3d4bf8ed5:

$ grep NO_PROXY /etc/login.conf
:setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO_PROXY
NO_PROXY=localhost,*.siemens.net

Re: Delay in 14.0-RELEASE cycle and blocking items

[Yuri]

Michael Osipov wrote:
> Am 2023-05-15 um 21:37 schrieb Glen Barber:
>> On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
>>> Glen,
>>>
>>> do you see any chance to get this finally merged:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
>>>
>>> It seriously affects people (in enterprises) behind a proxy, curl will
>>> be a problem and py-requests is already a serious problem.
>>>
>>
>> I have bumped the bug, and pinged sef@ and cc'd re@ as a result.
>>
>> I do not see a problem with it, as long as it is a proper fix.
> 
> Thank you! I have verified the patch back then, will happily re-verify
> if requested to.

I just tried this (without patching):

$ cat ~/.login_conf
me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
$ env | egrep 'FOO|BAR|BAZ'
BAZ=foo,bar
BAR=baz
FOO=bar

It looks like single-quotes should do the trick, and we simply need to
document this?

Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support

[Yuri]

Warner Losh wrote:
> 
> 
> On Thu, May 11, 2023, 2:50 PM Rodney W. Grimes
> mailto:freebsd-...@gndrsh.dnsmgr.net>>
> wrote:
> 
> > On Thu, May 11, 2023, 2:16 PM Yuri  <mailto:y...@aetern.org>> wrote:
> >
> > > Warner Losh wrote:
> > > > The branch main has been updated by imp:
> > > >
> > > > URL:
> > >
> 
> https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0
>  
> <https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0>
> > > >
> > > > commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> > > > Author:     Warner Losh 
> > > > AuthorDate: 2023-05-11 20:04:12 +
> > > > Commit:     Warner Losh 
> > > > CommitDate: 2023-05-11 20:06:03 +
> > > >
> > > >     stand/efi: Retire i386 support
> > > >
> > > >     Remove the i386 ifdefs and files. It never worked.
> > > >
> > > >     Sponsored by:           Netflix
> > > >     Reviewed by:            manu, tsoome, kevans
> > > >     Differential Revision:  https://reviews.freebsd.org/D40012
> <https://reviews.freebsd.org/D40012>
> > >
> > > As this question seems to be asked a lot on the forums, does
> this mean
> > > we will never support the 32bit efi booting 64bit OS?
> > >
> >
> > Yes. It means we've given up on that. Such environments are rare these
> > days, as far as I know, so unless someone shows up with something that
> > works perfectly with a qemu testing recipe that we can roll it
> into out
> > test bed. Plus some kind of info on real hardware that does this
> that's
> > popular enough to justify inclusion.
> 
> I have only ever seen 1 implementation of x86 32bit efi, and it was
> such a pile of turds I just scrapped the machine.
> 
> 
> That was my experience as well, so I biased my action towards just
> removing it. If it turns out my experience was somehow atypical and
> these are popular and very much robust, I'm open to learning about it.

I just noticed that it was asked several times in the last few months
trying to use FreeBSD on not-so-modern and rather exotic hardware; I
don't think we really need that support, but I simply wasn't aware of
efi32 status before this commit, hence I asked :)

Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support

[Yuri]

Warner Losh wrote:
> The branch main has been updated by imp:
> 
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> 
> commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0
> Author: Warner Losh 
> AuthorDate: 2023-05-11 20:04:12 +
> Commit: Warner Losh 
> CommitDate: 2023-05-11 20:06:03 +
> 
> stand/efi: Retire i386 support
> 
> Remove the i386 ifdefs and files. It never worked.
> 
> Sponsored by:   Netflix
> Reviewed by:manu, tsoome, kevans
> Differential Revision:  https://reviews.freebsd.org/D40012

As this question seems to be asked a lot on the forums, does this mean
we will never support the 32bit efi booting 64bit OS?

Re: adopting zone1970.tab changes in tzsetup

[Yuri]

Yuri wrote:
> Hi,
> 
> After tzsetup was switched to use zone1970.tab in 513419f4047 it mostly
> works, but there are some content changes compared to zone.tab that was
> used previously which need to be taken care of (would like to do so
> before 14.0).  If you have spare time, please take a look at the reviews
> below.
> 
> https://reviews.freebsd.org/D39634 - add baseline to tzsetup to check
> that zone1970.tab changes don't break the assumptions of file format we
> make in tzsetup (and tzsetup changes itself don't have unintended effects)

This one is integrated.

> https://reviews.freebsd.org/D39606 - adopt zone1970.tab changes
> - assumption that single-zone countries do not have description is no
>   longer correct; do not try to optimize this case as it's only going to
>   make the code more confusing and we now have menus with a single zone
>   selection because of this
> - remove the single-country continent short cut, it also only serves to
>   confuse users as we now have such a continent
> - instead add a single-zone contry short cut (see above), now all
>   single-zone countries fall here
> - use the @# continent overrides that zone1970.tab introduces (this is
>   visible at least fixing Iceland being currently listed under Africa)
> - add Arctic Ocean "continent" coming only from the overrides at the
>   moment
> - update baseline with the changes

And this one is waiting for review :)

Re: github CI failures related to tzsetup

[Yuri]

Yuri wrote:
> Looking at the CI jobs on github, all seem to fail in tzsetup while
> making kernel-toolchain target.  Obviously this build for me locally,
> FreeBSD's CI is fine with it, it's only ubuntu and macos jobs reporting
> the errors, and I don't see why; any hints?
> 
> https://github.com/freebsd/freebsd-src/actions/runs/4808074516/jobs/8557602371#step:7:878
> 
> ===> usr.sbin/tzsetup (obj,all,install)
> /home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c: In
> function ‘dump_zonetab’:
> /home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c:809:12:
> error: ‘countries’ undeclared (first use in this function); did you mean
> ‘country’?
>   809 |  for (cp = countries; cp->name != NULL; cp++) {
>   |^
>   |country
> 

Got it, the definition is hidden under the ifdef BSDDIALOG, will fix.

github CI failures related to tzsetup

[Yuri]

Looking at the CI jobs on github, all seem to fail in tzsetup while
making kernel-toolchain target.  Obviously this build for me locally,
FreeBSD's CI is fine with it, it's only ubuntu and macos jobs reporting
the errors, and I don't see why; any hints?

https://github.com/freebsd/freebsd-src/actions/runs/4808074516/jobs/8557602371#step:7:878

===> usr.sbin/tzsetup (obj,all,install)
/home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c: In
function ‘dump_zonetab’:
/home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c:809:12:
error: ‘countries’ undeclared (first use in this function); did you mean
‘country’?
  809 |  for (cp = countries; cp->name != NULL; cp++) {
  |^
  |country

Re: find(1): I18N gone wild? [[:alpha:]] not a substitute to refer 26 English letters A-Z

[Yuri]

Yuri wrote:
> parv/FreeBSD wrote:
>> Wrote Dimitry Andric on Fri, 21 Apr 2023 10:38:05 UTC
>> (via
>> https://lists.freebsd.org/archives/freebsd-current/2023-April/003556.html 
>> <https://lists.freebsd.org/archives/freebsd-current/2023-April/003556.html> )
>>>
>>> ... However, I have read that with unicode, you should *never*
>>> use [A-Z] or [0-9], but character classes instead. That seems to give
>>> both files on macOS and Linux with [[:alpha:]]:
>> ...
>>
>> Subject to the locale, problem with that is "[[:alpha:]]" will match
>> more than 26 English letters "A" through "Z" (besides also matching
>> lower case "a" through "z") even if none of 26 * 2 English alphabets
>> appear in a string.
> 
> (replying to random recent message)
> 
> And there is a bit of quite recent history for fnmatch() related to
> [a-z], same was done for regex with the same outcome -- attempt to make
> [a-z] (guess [A-Z] as well) range non-collating failed.  I am not aware
> of the encountered failures, hopefully someone should remember:

I just tried less intrusive change that seems to help with these ranges
(but there's still a question what failed previously):

diff --git a/lib/libc/gen/fnmatch.c b/lib/libc/gen/fnmatch.c
index 40670545993..3234c14 100644
--- a/lib/libc/gen/fnmatch.c
+++ b/lib/libc/gen/fnmatch.c
@@ -295,10 +295,11 @@ rangematch(const char *pattern, wchar_t test, int
flags, char **newp,
if (flags & FNM_CASEFOLD)
c2 = towlower(c2);

-   if (table->__collate_load_error ?
+   if (table->__collate_load_error ||
+   iswascii(test) ?
c <= test && test <= c2 :
-  __wcollate_range_cmp(c, test) <= 0
-   && __wcollate_range_cmp(test, c2) <= 0
+   __wcollate_range_cmp(c, test) <= 0 &&
+   __wcollate_range_cmp(test, c2) <= 0
   )
    ok = 1;
} else if (c == test)

$ LC_ALL=en_US.UTF-8
LD_PRELOAD=/usr/obj/home/yuri/ws/find/amd64.amd64/lib/libc/libc.so.7
find . -name '[a-z]*'
./bar
$ LC_ALL=en_US.UTF-8
LD_PRELOAD=/usr/obj/home/yuri/ws/find/amd64.amd64/lib/libc/libc.so.7
find . -name '[A-Z]*'
./FOO

> 
> commit 5a5807dd4ca34467ac5fb458bc19f12bf62075a5
> Author: Andrey A. Chernov 
> Date:   Sun Jul 10 03:49:38 2016 +
> 
> Remove broken support for collation in [a-z] type ranges.
> Only first 256 wide chars are considered currently, all other are just
> dropped from the range. Proper implementation require reverse tables
> database lookup, since objects are really big as max UTF-8 (1114112
> code points), so just the same scanning as it was for 256 chars will
> slow things down.
> 
> POSIX does not require collation for [a-z] type ranges and does not
> prohibit it for non-POSIX locales. POSIX require collation for ranges
> only for POSIX (or C) locale which is equal to ASCII and binary for
> other chars, so we already have it.
> 
> No other *BSD implements collation for [a-z] type ranges.
> 
> Restore ABI compatibility with unused now __collate_range_cmp() which
> is visible from outside (will be removed later).
> 
> commit 1daad8f5ad767dfe7896b8d1959a329785c9a76b
> Author: Andrey A. Chernov 
> Date:   Thu Jul 14 08:18:12 2016 +
> 
> Back out non-collating [a-z] ranges.
> Instead of changing whole course to another POSIX-permitted way
> for consistency and uniformity I decide to completely ignore missing
> regex fucntionality and concentrace on fixing bugs in what we have now,
> too many small obstacles instead, counting ports.
> 
> commit 12eae8c8f346cb459a388259ca98faebdac47038
> Author: Andrey A. Chernov 
> Date:   Thu Jul 14 09:07:25 2016 +
> 
> 1) Eliminate possibility to call __*collate_range_cmp() with inclomplete
> locale (which cause core dump) by removing whole 'table' argument
> by which it passed.
> 
> 2) Restore __collate_range_cmp() in __sccl().
> 
> 3) Collating [a-z] range in regcomp() only for single bytes locales
> (we can't do it now for other ones). In previous state only first 256
> wchars are considered and all others are just silently dropped from the
> range.
> 
> 

Re: find(1): I18N gone wild? [[:alpha:]] not a substitute to refer 26 English letters A-Z

[Yuri]

parv/FreeBSD wrote:
> Wrote Dimitry Andric on Fri, 21 Apr 2023 10:38:05 UTC
> (via
> https://lists.freebsd.org/archives/freebsd-current/2023-April/003556.html 
>  )
>>
>> ... However, I have read that with unicode, you should *never*
>> use [A-Z] or [0-9], but character classes instead. That seems to give
>> both files on macOS and Linux with [[:alpha:]]:
> ...
> 
> Subject to the locale, problem with that is "[[:alpha:]]" will match
> more than 26 English letters "A" through "Z" (besides also matching
> lower case "a" through "z") even if none of 26 * 2 English alphabets
> appear in a string.

(replying to random recent message)

And there is a bit of quite recent history for fnmatch() related to
[a-z], same was done for regex with the same outcome -- attempt to make
[a-z] (guess [A-Z] as well) range non-collating failed.  I am not aware
of the encountered failures, hopefully someone should remember:


commit 5a5807dd4ca34467ac5fb458bc19f12bf62075a5
Author: Andrey A. Chernov 
Date:   Sun Jul 10 03:49:38 2016 +

Remove broken support for collation in [a-z] type ranges.
Only first 256 wide chars are considered currently, all other are just
dropped from the range. Proper implementation require reverse tables
database lookup, since objects are really big as max UTF-8 (1114112
code points), so just the same scanning as it was for 256 chars will
slow things down.

POSIX does not require collation for [a-z] type ranges and does not
prohibit it for non-POSIX locales. POSIX require collation for ranges
only for POSIX (or C) locale which is equal to ASCII and binary for
other chars, so we already have it.

No other *BSD implements collation for [a-z] type ranges.

Restore ABI compatibility with unused now __collate_range_cmp() which
is visible from outside (will be removed later).

commit 1daad8f5ad767dfe7896b8d1959a329785c9a76b
Author: Andrey A. Chernov 
Date:   Thu Jul 14 08:18:12 2016 +

Back out non-collating [a-z] ranges.
Instead of changing whole course to another POSIX-permitted way
for consistency and uniformity I decide to completely ignore missing
regex fucntionality and concentrace on fixing bugs in what we have now,
too many small obstacles instead, counting ports.

commit 12eae8c8f346cb459a388259ca98faebdac47038
Author: Andrey A. Chernov 
Date:   Thu Jul 14 09:07:25 2016 +

1) Eliminate possibility to call __*collate_range_cmp() with inclomplete
locale (which cause core dump) by removing whole 'table' argument
by which it passed.

2) Restore __collate_range_cmp() in __sccl().

3) Collating [a-z] range in regcomp() only for single bytes locales
(we can't do it now for other ones). In previous state only first 256
wchars are considered and all others are just silently dropped from the
range.

Re: find(1): I18N gone wild ?

[Yuri]

Jamie Landeg-Jones wrote:
> Yuri  wrote:
> 
>> No, find "-name" works with pattern rules in the first link, please see:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
> 
> Yeah. *blush* Sorry about that. I had thought character classes were
> for regular expressions only.

No worries, I too am trying to understand the problem completely, which
comes in form of (too many) links :-)

Re: find(1): I18N gone wild ?

[Yuri]

Jamie Landeg-Jones wrote:
> Yuri  wrote:
> 
>>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13
>>>
>>> ...which in turn refers to the following link for bracket expressions:
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
>>>
>>> Why we don't support all of that is different story.
>>
>> A bit more on this; first link applies both to find(1) and fnmatch(3),
>> and find uses fnmatch() internally (which is good), but even the
>> function that processes bracket expressions is called rangematch() and
>> that's really all it does ignoring other bracket expression rules:
>>
>> https://cgit.freebsd.org/src/tree/lib/libc/gen/fnmatch.c#n234
>>
>> So to "fix" find we just need to implement the bracket expressions
>> properly in fnmatch().
> 
> No. find "-name" works with GLOBs not regex.

No, find "-name" works with pattern rules in the first link, please see:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html

> The functionality you are talking about, and the page you quoted refer to 
> regular expressions.

The functionality I am talking about is defined in find specification
above, the only relation to REs is for bracket expressions (with !
instead of ^).

> For that, you use find "-regex" - note that the regex is assumed anchored, so:
> 
> $ LANG=en_US.UTF-8 find -E /etc/rc.d -regex '.*[[:upper:]]+' -print
> /etc/rc.d/NETWORKING
> /etc/rc.d/FILESYSTEMS
> /etc/rc.d/SERVERS
> /etc/rc.d/DAEMON
> /etc/rc.d/LOGIN
> $
> 
> Jamie
> 

Re: find(1): I18N gone wild ?

[Yuri]

Yuri wrote:
> Mark Millard wrote:
>> Dimitry Andric  wrote on
>> Date: Fri, 21 Apr 2023 10:38:05 UTC :
>>
>>> On 21 Apr 2023, at 12:01, Ronald Klop  wrote:
>>>> Van: Poul-Henning Kamp 
>>>> Datum: maandag, 17 april 2023 23:06
>>>> Aan: curr...@freebsd.org
>>>> Onderwerp: find(1): I18N gone wild ?
>>>> This surprised me:
>>>>
>>>> # mkdir /tmp/P
>>>> # cd /tmp/P
>>>> # touch FOO
>>>> # touch bar
>>>> # env LANG=C.UTF-8 find . -name '[A-Z]*' -print
>>>> ./FOO
>>>> # env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
>>>> ./FOO
>>>> ./bar
>>>>
>>>> Really ?!
>>> ...
>>>> My Mac and a Linux server only give ./FOO in both cases. Just a 2 cents 
>>>> remark.
>>>
>>> Same here. However, I have read that with unicode, you should *never*
>>> use [A-Z] or [0-9], but character classes instead. That seems to give
>>> both files on macOS and Linux with [[:alpha:]]:
>>>
>>> $ LANG=en_US.UTF-8 find . -name '[[:alpha:]]*' -print
>>> ./BAR
>>> ./foo
>>>
>>> and only the lowercase file with [[:lower:]]:
>>>
>>> $ LANG=en_US.UTF-8 find . -name '[[:lower:]]*' -print
>>> ./foo
>>>
>>> But on FreeBSD, these don't work at all:
>>>
>>> $ LANG=en_US.UTF-8 find . -name '[[:alpha:]]*' -print
>>> 
>>>
>>> $ LANG=en_US.UTF-8 find . -name '[[:lower:]]*' -print
>>> 
>>>
>>> This is an interesting rabbit hole... :)
>>
>> FreeBSD:
>>
>>  -name pattern
>>  True if the last component of the pathname being examined 
>> matches
>>  pattern.  Special shell pattern matching characters (“[”, “]”,
>>  “*”, and “?”) may be used as part of pattern.  These characters
>>  may be matched explicitly by escaping them with a backslash
>>  (“\”).
>>
>> I conclude that [[:alpha:]] and [[:lower:]] were not
>> considered "Special shell pattern"s. "man glob"
>> indicates it is a shell specific builtin.
>>
>> macOS says similarly. Different shells, different
>> pattern notations and capabilities? Well, "man bash"
>> reports:
> [snip]
>> Seems like: pick your shell (as shown by echo $SHELL) and
>> that picks the pattern match rules used. (May be controllable
>> in the specific shell.)
> 
> No, the pattern is not passed to shell and shell used should not matter
> (pattern should be properly escaped).  The rules are here:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13
> 
> ...which in turn refers to the following link for bracket expressions:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
> 
> Why we don't support all of that is different story.

A bit more on this; first link applies both to find(1) and fnmatch(3),
and find uses fnmatch() internally (which is good), but even the
function that processes bracket expressions is called rangematch() and
that's really all it does ignoring other bracket expression rules:

https://cgit.freebsd.org/src/tree/lib/libc/gen/fnmatch.c#n234

So to "fix" find we just need to implement the bracket expressions
properly in fnmatch().

Re: find(1): I18N gone wild ?

[Yuri]

Mark Millard wrote:
> Dimitry Andric  wrote on
> Date: Fri, 21 Apr 2023 10:38:05 UTC :
> 
>> On 21 Apr 2023, at 12:01, Ronald Klop  wrote:
>>> Van: Poul-Henning Kamp 
>>> Datum: maandag, 17 april 2023 23:06
>>> Aan: curr...@freebsd.org
>>> Onderwerp: find(1): I18N gone wild ?
>>> This surprised me:
>>>
>>> # mkdir /tmp/P
>>> # cd /tmp/P
>>> # touch FOO
>>> # touch bar
>>> # env LANG=C.UTF-8 find . -name '[A-Z]*' -print
>>> ./FOO
>>> # env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
>>> ./FOO
>>> ./bar
>>>
>>> Really ?!
>> ...
>>> My Mac and a Linux server only give ./FOO in both cases. Just a 2 cents 
>>> remark.
>>
>> Same here. However, I have read that with unicode, you should *never*
>> use [A-Z] or [0-9], but character classes instead. That seems to give
>> both files on macOS and Linux with [[:alpha:]]:
>>
>> $ LANG=en_US.UTF-8 find . -name '[[:alpha:]]*' -print
>> ./BAR
>> ./foo
>>
>> and only the lowercase file with [[:lower:]]:
>>
>> $ LANG=en_US.UTF-8 find . -name '[[:lower:]]*' -print
>> ./foo
>>
>> But on FreeBSD, these don't work at all:
>>
>> $ LANG=en_US.UTF-8 find . -name '[[:alpha:]]*' -print
>> 
>>
>> $ LANG=en_US.UTF-8 find . -name '[[:lower:]]*' -print
>> 
>>
>> This is an interesting rabbit hole... :)
> 
> FreeBSD:
> 
>  -name pattern
>  True if the last component of the pathname being examined matches
>  pattern.  Special shell pattern matching characters (“[”, “]”,
>  “*”, and “?”) may be used as part of pattern.  These characters
>  may be matched explicitly by escaping them with a backslash
>  (“\”).
> 
> I conclude that [[:alpha:]] and [[:lower:]] were not
> considered "Special shell pattern"s. "man glob"
> indicates it is a shell specific builtin.
> 
> macOS says similarly. Different shells, different
> pattern notations and capabilities? Well, "man bash"
> reports:
[snip]
> Seems like: pick your shell (as shown by echo $SHELL) and
> that picks the pattern match rules used. (May be controllable
> in the specific shell.)

No, the pattern is not passed to shell and shell used should not matter
(pattern should be properly escaped).  The rules are here:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13

...which in turn refers to the following link for bracket expressions:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05

Why we don't support all of that is different story.

adopting zone1970.tab changes in tzsetup

[Yuri]

Hi,

After tzsetup was switched to use zone1970.tab in 513419f4047 it mostly
works, but there are some content changes compared to zone.tab that was
used previously which need to be taken care of (would like to do so
before 14.0).  If you have spare time, please take a look at the reviews
below.

https://reviews.freebsd.org/D39634 - add baseline to tzsetup to check
that zone1970.tab changes don't break the assumptions of file format we
make in tzsetup (and tzsetup changes itself don't have unintended effects)

https://reviews.freebsd.org/D39606 - adopt zone1970.tab changes
- assumption that single-zone countries do not have description is no
  longer correct; do not try to optimize this case as it's only going to
  make the code more confusing and we now have menus with a single zone
  selection because of this
- remove the single-country continent short cut, it also only serves to
  confuse users as we now have such a continent
- instead add a single-zone contry short cut (see above), now all
  single-zone countries fall here
- use the @# continent overrides that zone1970.tab introduces (this is
  visible at least fixing Iceland being currently listed under Africa)
- add Arctic Ocean "continent" coming only from the overrides at the
  moment
- update baseline with the changes

Re: find(1): I18N gone wild ?

[Yuri]

Xin LI wrote:
> This is expected behavior (in en_US.UTF-8 the ordering is AaBb, not
> ABab).  You might want to set LC_COLLATE to C if C behavior is desirable.
> 
> On Mon, Apr 17, 2023 at 2:06 PM Poul-Henning Kamp  > wrote:
> 
> This surprised me:
> 
>         # mkdir /tmp/P
>         # cd /tmp/P
>         # touch FOO
>         # touch bar
>         # env LANG=C.UTF-8 find . -name '[A-Z]*' -print
>         ./FOO
>         # env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
>         ./FOO
>         ./bar
> 
> Really ?!

A bit more detail:

find uses fnmatch(3) here, where the RE Bracket Expression rules apply
(except for ! instead of ^, but that's unrelated):

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05

...which has the following note:

7. In the POSIX locale, a range expression represents the set of
collating elements that fall between two elements in the collation
sequence, inclusive. In other locales, a range expression has
unspecified behavior: strictly conforming applications shall not rely on
whether the range expression is valid, or on the set of collating
elements matched.

Indeed, it's unfortunate that collations in non-POSIX are not that...
linear and range expressions can break, but I don't see an easy way of
"fixing" this.

Re: byteswap.h not found on 12 and 13

[Yuri]

Nuno Teixeira wrote:
> Hello Warner,
> 
> My poudriere jails:
> ---
> 124amd64   12.4-RELEASE-p2      amd64         http         2023-03-17
> 08:04:15 /usr/local/poudriere/jails/124amd64
> 124i386    12.4-RELEASE-p2      i386          http         2023-03-17
> 08:04:38 /usr/local/poudriere/jails/124i386
> 131amd64   13.1-RELEASE-p7      amd64         http         2023-03-17
> 08:05:03 /usr/local/poudriere/jails/131amd64
> ---
> 
> The strange thing is that 5.08 (old version) have #include 
> too and compiles fine|:
> |
> https://github.com/sflow/sflowtool/issues/41
> 

5.08 seems to have it commented out:

sflowtool-5.08/src/sflowtool.c:

/*
#ifdef DARWIN
#include 
#define bswap_16(x) NXSwapShort(x)
#define bswap_32(x) NXSwapInt(x)
#else
#include 
#endif
*/


> Warner Losh mailto:i...@bsdimp.com>> escreveu no dia
> sexta, 24/03/2023 à(s) 08:30:
> 
> 
> 
> On Fri, Mar 24, 2023, 9:23 AM Nuno Teixeira  > wrote:
> 
> Hello all,
> 
> I'm getting a file not found on 12 and 13 compiling
> net/sflowtool latest update:
> It compile fine on 14.
> 
> I've searched 14 src and found:
> ---
> ./include/byteswap.h
> ./contrib/ofed/include/byteswap.h
> ./contrib/llvm-project/libcxx/include/__bit/byteswap.h
> ---
> Any clues?
> 
> 
> 
> I added it a short time ago. I thought I mfc'd it to 13 but not 12.
> How recent a 13? It's a non standard glibc extension that may be in
> the next posix standard though. I've not looked at the draft for it
> yet to see if it complies or not.
> 
> Warner
> 
> Thanks,
> 
> ---
> ===>  Building for sflowtool-6.01
> --- all ---
> /usr/bin/make  all-recursive
> --- all-recursive ---
> Making all in src
> --- sflowtool.o ---
> cc -DHAVE_CONFIG_H -I. -I..      -O2 -pipe
>  -fstack-protector-strong -fno-strict-aliasing -MT sflowtool.o
> -MD -MP -MF .deps/sflowtool.Tpo -c -o sflowtool.o sflowtool.c
> sflowtool.c:32:10: fatal error: 'byteswap.h' file not found
> #include 
>          ^~~~
> 1 error generated.
> *** [sflowtool.o] Error code 1
> ---
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)
> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

dangling symlinks in openzfs import

[Yuri]

These have been in there for quite some time now, and every time I try
to grep something I see this (I know about -s option, but it's there in
opengrok and other tools output as well):

grep:
sys/contrib/openzfs/contrib/debian/openzfs-zfsutils.zfs-load-key.init:
No such file or directory
grep:
sys/contrib/openzfs/contrib/debian/openzfs-zfsutils.zfs-mount.init: No
such file or directory
grep:
sys/contrib/openzfs/contrib/debian/openzfs-zfsutils.zfs-import.init: No
such file or directory
grep:
sys/contrib/openzfs/contrib/debian/openzfs-zfsutils.zfs-share.init: No
such file or directory
grep: sys/contrib/openzfs/contrib/debian/openzfs-zfs-zed.zfs-zed.init:
No such file or directory

Given that these files are completely unrelated to FreeBSD, is it
possible to exclude them from merging with upstream (and delete), or
would it break something?

Re: Infinite loop with d_write_t

[Yuri]

Goran Mekić wrote:
> Hello,
> 
> I'm trying to assemble a minimal kernel module and user space program as
> a skeleton, and no matter what I do I get infinite loop. The code for
> kernel is 
> https://github.com/mekanix/freebsd-project/blob/master/kernel/main.c.
> The way to test:
> # make
> # sudo kldload ./hello.ko
> # echo "something" >/dev/hello
> Write done.
> Write done.
> ...
> 
> What am I doing wrong and where does that infinite loop comes from?

Why are you using copyin() and not uiomove() in d_write entry?

There's an example that looks like you are trying to do:

https://docs.freebsd.org/en/books/arch-handbook/driverbasics/#driverbasics-char

Re: vt and keyboard accents

[Yuri]

Hans Petter Selasky wrote:
> On 1/29/23 09:48, Yuri wrote:
>> Hans Petter Selasky wrote:
>>> On 1/29/23 01:54, Yuri wrote:
>>>> Looking into an issue with accents input for vt and cz (so
>>>> /usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
>>>> working and other result weird unrelated characters output.
>>>>
>>>> Checking kbdcontrol -d output, there is an obvious difference with
>>>> keymap contents -- all mappings are trimmed down to 1 byte after
>>>> reading:
>>>>
>>>> kbdcontrol:
>>>>     dacu  180  ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
>>>>    ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
>>>>    ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
>>>>    ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
>>>>    ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
>>>>    ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
>>>>    ( 'y' 253 )
>>>>
>>>> keymap:
>>>>     dacu 0xb4    ( 0xb4   0xb4    ) ( 'S'    0x015a  ) ( 'Z'   
>>>> 0x0179  )
>>>> ( 's'    0x015b  )
>>>>  ( 'z'    0x017a  ) ( 'R'    0x0154  ) ( 'A'   
>>>> 0xc1    )
>>>> ( 'L'    0x0139  )
>>>>  ( 'C'    0x0106  ) ( 'E'    0xc9    ) ( 'I'   
>>>> 0xcd    )
>>>> ( 'N'    0x0143  )
>>>>  ( 'O'    0xd3    ) ( 'U'    0xda    ) ( 'Y'   
>>>> 0xdd    )
>>>> ( 'r'    0x0155  )
>>>>  ( 'a'    0xe1    ) ( 'l'    0x013a  ) ( 'c'   
>>>> 0x0107  )
>>>> ( 'e'    0xe9    )
>>>>  ( 'i'    0xed    ) ( 'n'    0x0144  ) ( 'o'   
>>>> 0xf3    )
>>>> ( 'u'    0xfa    )
>>>>  ( 'y'    0xfd    )
>>>>
>>>> Source of the problem is the following definition in sys/sys/kbio.h:
>>>>
>>>> struct acc_t {
>>>>   u_char  accchar;
>>>>   u_char  map[NUM_ACCENTCHARS][2];
>>>> };
>>>>
>>>> While the keymaps were converted to have the unicode characters for vt
>>>> in the commit below, the array to store them (map) was missed, or was
>>>> there a reason for this?
>>>>
>>>> ---
>>>> commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
>>>> Author: Stefan Eßer 
>>>> Date:   Sun Aug 17 19:54:21 2014 +
>>>>
>>>>   Attempt at converting the SYSCONS keymaps to Unicode for use with
>>>> NEWCONS.
>>>>   I have spent many hours comparing source and destination formats,
>>>> and hope
>>>>   to have caught the most severe conversion errors.
>>>> ---
>>>>
>>>> I have tried the following patch and it allows me to enter all accents
>>>> documented in the keymap, though I must admit I'm not sure it does not
>>>> have hidden issues:
>>>>
>>>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
>>>> index 7f17bda76c5..fffeb63e226 100644
>>>> --- a/sys/sys/kbio.h
>>>> +++ b/sys/sys/kbio.h
>>>> @@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
>>>>
>>>>    struct acc_t {
>>>>   u_char  accchar;
>>>> -   u_char  map[NUM_ACCENTCHARS][2];
>>>> +   int map[NUM_ACCENTCHARS][2];
>>>>    };
>>>>
>>>
>>> Hi,
>>>
>>> Using "int" for unicode characters is probably good for now. Your patch
>>> looks good, but please also consider the "umlaut" case while at it
>>> (multiple characters that become one)!
>>
>> I think umlauts are already part of "accents" (duml keyword), e.g. in
>> cz.kbd:
>>
>>    duml 0xa8    ( 0xa8   0xa8    ) ( 'A'    0xc4    ) ( 'E'    0xcb    )
>> ( 'O'    0xd6    )
>>     ( 'U'    0xdc    ) ( 'a'    0xe4    ) ( 'e'    0xeb    )
>> ( 'o'    0xf6    )
>>     ( 'u'    0xfc    )
>>
>> So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
>> keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
>> of the ÄËÖÜäëöü characters can be written as single-byte unicode.
>>
>> And the following dcar (that is, "caron") characters are all broken as
&g

Re: vt and keyboard accents

[Yuri]

Hans Petter Selasky wrote:
> On 1/29/23 01:54, Yuri wrote:
>> Looking into an issue with accents input for vt and cz (so
>> /usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
>> working and other result weird unrelated characters output.
>>
>> Checking kbdcontrol -d output, there is an obvious difference with
>> keymap contents -- all mappings are trimmed down to 1 byte after reading:
>>
>> kbdcontrol:
>>    dacu  180  ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
>>   ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
>>   ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
>>   ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
>>   ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
>>   ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
>>   ( 'y' 253 )
>>
>> keymap:
>>    dacu 0xb4    ( 0xb4   0xb4    ) ( 'S'    0x015a  ) ( 'Z'    0x0179  )
>> ( 's'    0x015b  )
>>     ( 'z'    0x017a  ) ( 'R'    0x0154  ) ( 'A'    0xc1    )
>> ( 'L'    0x0139  )
>>     ( 'C'    0x0106  ) ( 'E'    0xc9    ) ( 'I'    0xcd    )
>> ( 'N'    0x0143  )
>>     ( 'O'    0xd3    ) ( 'U'    0xda    ) ( 'Y'    0xdd    )
>> ( 'r'    0x0155  )
>>     ( 'a'    0xe1    ) ( 'l'    0x013a  ) ( 'c'    0x0107  )
>> ( 'e'    0xe9    )
>>     ( 'i'    0xed    ) ( 'n'    0x0144  ) ( 'o'    0xf3    )
>> ( 'u'    0xfa    )
>>     ( 'y'    0xfd    )
>>
>> Source of the problem is the following definition in sys/sys/kbio.h:
>>
>> struct acc_t {
>>  u_char  accchar;
>>  u_char  map[NUM_ACCENTCHARS][2];
>> };
>>
>> While the keymaps were converted to have the unicode characters for vt
>> in the commit below, the array to store them (map) was missed, or was
>> there a reason for this?
>>
>> ---
>> commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
>> Author: Stefan Eßer 
>> Date:   Sun Aug 17 19:54:21 2014 +
>>
>>  Attempt at converting the SYSCONS keymaps to Unicode for use with
>> NEWCONS.
>>  I have spent many hours comparing source and destination formats,
>> and hope
>>  to have caught the most severe conversion errors.
>> ---
>>
>> I have tried the following patch and it allows me to enter all accents
>> documented in the keymap, though I must admit I'm not sure it does not
>> have hidden issues:
>>
>> diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
>> index 7f17bda76c5..fffeb63e226 100644
>> --- a/sys/sys/kbio.h
>> +++ b/sys/sys/kbio.h
>> @@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;
>>
>>   struct acc_t {
>>  u_char  accchar;
>> -   u_char  map[NUM_ACCENTCHARS][2];
>> +   int map[NUM_ACCENTCHARS][2];
>>   };
>>
> 
> Hi,
> 
> Using "int" for unicode characters is probably good for now. Your patch
> looks good, but please also consider the "umlaut" case while at it
> (multiple characters that become one)!

I think umlauts are already part of "accents" (duml keyword), e.g. in
cz.kbd:

  duml 0xa8( 0xa8   0xa8) ( 'A'0xc4) ( 'E'0xcb)
( 'O'0xd6)
   ( 'U'0xdc) ( 'a'0xe4) ( 'e'0xeb)
( 'o'0xf6)
   ( 'u'0xfc)

So pressing Alt+Shift and "=/+" key, and then pressing one of AEOUaeou
keys would produce ÄËÖÜäëöü, respectively, and it currently works as all
of the ÄËÖÜäëöü characters can be written as single-byte unicode.

And the following dcar (that is, "caron") characters are all broken as
they need at least 2 bytes, pressing Shift and "=/+" key, and any of the
LSTZlstzCEDNRcednrUu would print nothing at all, produce garbage, or
print some control character (last byte only):

  dcar 0x02c7  ( 0x02c7 0x02c7  ) ( 'L'0x013d  ) ( 'S'0x0160  )
( 'T'0x0164  )
   ( 'Z'0x017d  ) ( 'l'0x013e  ) ( 's'0x0161  )
( 't'0x0165  )
   ( 'z'0x017e  ) ( 'C'0x010c  ) ( 'E'0x011a  )
( 'D'0x010e  )
   ( 'N'0x0147  ) ( 'R'0x0158  ) ( 'c'0x010d  )
( 'e'0x011b  )
   ( 'd'0x010f  ) ( 'n'0x0148  ) ( 'r'0x0159  )
( 'U'0x016e  )
   ( 'u'0x016f  )

vt and keyboard accents

[Yuri]

Looking into an issue with accents input for vt and cz (so
/usr/share/vt/keymaps/cz.kbd) keyboard where some of the accents are
working and other result weird unrelated characters output.

Checking kbdcontrol -d output, there is an obvious difference with
keymap contents -- all mappings are trimmed down to 1 byte after reading:

kbdcontrol:
  dacu  180  ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
 ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
 ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
 ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
 ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
 ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
 ( 'y' 253 )

keymap:
  dacu 0xb4( 0xb4   0xb4) ( 'S'0x015a  ) ( 'Z'0x0179  )
( 's'0x015b  )
   ( 'z'0x017a  ) ( 'R'0x0154  ) ( 'A'0xc1)
( 'L'0x0139  )
   ( 'C'0x0106  ) ( 'E'0xc9) ( 'I'0xcd)
( 'N'0x0143  )
   ( 'O'0xd3) ( 'U'0xda) ( 'Y'0xdd)
( 'r'0x0155  )
   ( 'a'0xe1) ( 'l'0x013a  ) ( 'c'0x0107  )
( 'e'0xe9)
   ( 'i'0xed) ( 'n'0x0144  ) ( 'o'0xf3)
( 'u'0xfa)
   ( 'y'0xfd)

Source of the problem is the following definition in sys/sys/kbio.h:

struct acc_t {
u_char  accchar;
u_char  map[NUM_ACCENTCHARS][2];
};

While the keymaps were converted to have the unicode characters for vt
in the commit below, the array to store them (map) was missed, or was
there a reason for this?

---
commit 7ba08f814546ece02e0193edc12cf6eb4d5cb8d4
Author: Stefan Eßer 
Date:   Sun Aug 17 19:54:21 2014 +

Attempt at converting the SYSCONS keymaps to Unicode for use with
NEWCONS.
I have spent many hours comparing source and destination formats,
and hope
to have caught the most severe conversion errors.
---

I have tried the following patch and it allows me to enter all accents
documented in the keymap, though I must admit I'm not sure it does not
have hidden issues:

diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;

 struct acc_t {
u_char  accchar;
-   u_char  map[NUM_ACCENTCHARS][2];
+   int map[NUM_ACCENTCHARS][2];
 };

Re: ld error (undefined symbol) while compiling sqlite3

[Yuri]

Archimedes Gaviola wrote:
> Hi,
> 
> For some reason, I am compiling sqlite3 from the
> /usr/src/contrib/sqlite3 source using
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837. I
> created a /usr/src/usr.bin/sqlite3 directory and created a Makefile file
> with content referred to the source.
> 
> root@generic:/usr/src/usr.bin/sqlite3 # ls -la
> total 16
> drwxr-xr-x    2 root  wheel   512 Nov 26 12:46 .
> drwxr-xr-x  279 root  wheel  5120 Nov 26 12:46 ..
> -rw-r--r--    1 root  wheel   295 Nov 26 16:50 Makefile
> 
> root@generic:/usr/src/usr.bin/sqlite3 # cat Makefile
> # $FreeBSD$
> 
> .include 
> 
> SQLITE= ${SRCTOP}/contrib/sqlite3
> .PATH:  ${SQLITE}
> 
> PROG= sqlite3
> MK_MAN=no
> SRCS= sqlite3.c

SRCS= shell.c sqlite3.c

> INCS= shell.c sqlite3.h

Remove?

> 
> WARNS?= 3

WARNS?= 2 worked for me.

> CFLAGS+=        -I${SQLITE} \
>                 -DSQLITE_THREADSAFE=0 \
>                 -DSQLITE_OMIT_LOAD_EXTENSION
> 
> .include 
> 
> With 'make' command invoked, I encountered this error -> ld: error:
> undefined symbol: main as referenced to the crt1_c.c:72
> (/usr/src/lib/csu/aarch64/crt1_c.c:72) file. See below details for the
> actual error.
> 
> root@generic:/usr/src/usr.bin/sqlite3 # make
> cc  -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3  -DSQLITE_THREADSAFE=1
>  -DSQLITE_OMIT_LOAD_EXTENSION   -fPIE -g -gz=zlib -MD  -MF.depend.sqlite3.o
> -MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member  -Qunused-arguments    -c
> /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o
> cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
> -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-error=unused-but-set-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
> sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
> -lpthread
> ld: error: undefined symbol: main
 referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
               /usr/lib/Scrt1.o:(__start)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/usr.bin/sqlite3
> 
> Not sure if I missed something or if something goes wrong with my Makefile
> content construction. I basically followed here
> https://www.sqlite.org/howtocompile.html
>  and then proved the source to
> compile successfully.
> 
> root@generic:/usr/src/contrib/sqlite3 # pwd
> /usr/src/contrib/sqlite3
> root@generic:/usr/src/contrib/sqlite3 # ls -lah
> total 11364
> drwxr-xr-x   3 root  wheel   1.0K Oct 27 08:06 .
> drwxr-xr-x  89 root  wheel   2.0K Nov 26 13:01 ..
> -rw-r--r--   1 root  wheel    15K Oct 27 08:06 INSTALL
> -rw-r--r--   1 root  wheel   729B Oct 27 08:06 Makefile.am
> -rw-r--r--   1 root  wheel   547B Oct 27 08:06 Makefile.fallback
> -rw-r--r--   1 root  wheel    37K Oct 27 08:06 Makefile.in
> -rw-r--r--   1 root  wheel    28K Oct 27 08:06 Makefile.msc
> -rw-r--r--   1 root  wheel   3.5K Oct 27 08:06 README.txt
> -rw-r--r--   1 root  wheel   7.1K Oct 27 08:06 Replace.cs
> -rw-r--r--   1 root  wheel   365K Oct 27 08:06 aclocal.m4
> -rwxr-xr-x   1 root  wheel   7.2K Oct 27 08:06 compile
> -rwxr-xr-x   1 root  wheel    48K Oct 27 08:06 config.guess
> -rwxr-xr-x   1 root  wheel    35K Oct 27 08:06 config.sub
> -rwxr-xr-x   1 root  wheel   485K Oct 27 08:06 configure
> -rw-r--r--   1 root  wheel   8.5K Oct 27 08:06 configure.ac
> 
> -rwxr-xr-x   1 root  wheel    23K Oct 27 08:06 depcomp
> -rwxr-xr-x   1 root  wheel    15K Oct 27 08:06 install-sh
> -rwxr-xr-x   1 root  wheel   320K Oct 27 08:06 ltmain.sh
> -rwxr-xr-x   1 root  wheel   6.7K Oct 27 08:06 missing
> -rw-r--r--   1 root  wheel   717K Oct 27 08:06 shell.c
> -rw-r--r--   1 root  wheel   8.7K Oct 27 08:06 sqlite3.1
> -rw-r--r--   1 root  wheel   8.2M Oct 27 08:06 sqlite3.c
> -rw-r--r--   1 root  wheel   599K Oct 27 08:06 sqlite3.h
> -rw-r--r--   1 root  wheel   267B Oct 27 08:06 sqlite3.pc.in
> 
> -rw-r--r--   1 root  wheel   1.9K Oct 27 08:06 

Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES

[Yuri]

Juraj Lutter wrote:
> 
> 
>> On 24 Nov 2022, at 15:16, Juraj Lutter  wrote:
>>>
>>> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
>>> that to your list.
>>>
>>
>> PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR 
>> into src-env.conf instead of /etc/src.conf, for that purpose.
> 
> Fingers are quicker than the brain: I’d put PORTSDIR into /etc/src.conf 
> instead of /etc/make.conf for that purpose.

Does it work for you?  I have tried putting it in all of the
/etc/src.conf, /etc/src-env.conf, and /etc/make.conf; still /usr/ports
is being used.

Looks like the expansion does not happen properly (for me, at least) in
kern.post.mk and the following seems to help (with PORTSDIR specified in
one of those 3 conf files or in environment):

diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk
index d08dfe30d7d..7b208510483 100644
--- a/sys/conf/kern.post.mk
+++ b/sys/conf/kern.post.mk
@@ -133,7 +133,7 @@ PORTSMODULESENV=\
 all:
 .for __i in ${PORTS_MODULES}
@${ECHO} "===> Ports module ${__i} (all)"
-   cd $${PORTSDIR:-/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE}
-B clean build
+   cd ${PORTSDIR:U/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE} -B
clean build
 .endfor

 .for __target in install reinstall clean
@@ -141,7 +141,7 @@ ${__target}: ports-${__target}
 ports-${__target}:
 .for __i in ${PORTS_MODULES}
@${ECHO} "===> Ports module ${__i} (${__target})"
-   cd $${PORTSDIR:-/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE}
-B ${__target:C/(re)?install/deinstall reinstall/}
+   cd ${PORTSDIR:U/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE} -B
${__target:C/(re)?install/deinstall reinstall/} .endfor
 .endfor
 .endif

emulated nvme on vmware workstation whines

[Yuri]

I started seeing the following whines from emulated nvme on vmware
workstation some time ago, and it seems to happen almost exclusively
during the nightly periodic run:

Jul  3 03:01:47 titan kernel: nvme0: RECOVERY_START 48053105730250 vs
48051555254036
Jul  3 03:01:47 titan kernel: nvme0: timeout with nothing complete,
resetting
Jul  3 03:01:47 titan kernel: nvme0: Resetting controller due to a timeout.
Jul  3 03:01:47 titan kernel: nvme0: RECOVERY_WAITING
Jul  3 03:01:47 titan kernel: nvme0: resetting controller
Jul  3 03:01:47 titan kernel: nvme0: temperature threshold not supported
Jul  3 03:01:47 titan kernel: nvme0: resubmitting queued i/o
Jul  3 03:01:47 titan kernel: nvme0: READ sqid:10 cid:0 nsid:1
lba:8931648 len:8
Jul  3 03:01:47 titan kernel: nvme0: aborting outstanding i/o
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_START 48207341204759 vs
48207032791553
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_START 48207722834338 vs
48207032791553
Jul  3 03:02:23 titan kernel: nvme0: timeout with nothing complete,
resetting
Jul  3 03:02:23 titan kernel: nvme0: Resetting controller due to a timeout.
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_WAITING
Jul  3 03:02:23 titan kernel: nvme0: resetting controller
Jul  3 03:02:23 titan kernel: nvme0: temperature threshold not supported
Jul  3 03:02:23 titan kernel: nvme0: aborting outstanding i/o
Jul  3 03:02:23 titan kernel: nvme0: resubmitting queued i/o
Jul  3 03:02:23 titan kernel: nvme0: WRITE sqid:1 cid:0 nsid:1
lba:27806528 len:8
Jul  3 03:02:23 titan kernel: nvme0: aborting outstanding i/o

It does not seem to break anything, i.e. no errors from periodic, zpool
status and zpool scrub do not show any issues as well, so I'm just
wondering if there is some obvious reason for this.

I am staying current with, well, -CURRENT and VMware Workstation
versions (now at 16.2.3), and do not remember when exactly this started.
 There are no other VMs doing anything at that time, host system is
pretty idle as well.

panic: make_dev_alias_v: bad si_name

[Yuri]

Getting the following panic on HPE system with HPE enclosure:

panic: make_dev_alias_v: bad si_name (error=22,
si_name=enc@n../type@0/slot@1/elmdesc@{"Name":"DriveBay1"}/pass4)

db_trace_self_wrapper()
vpanic()
panic()
make_dev_alias_v()
make_dev_alias_p()
make_dev_physpath_alias()
pass_add_physpath()
taskqueue_run_locked()
taskqueue_thread_loop()
fork_exit()
fork_trampoline()

I have skipped typing all the frame information as the cause of panic
seems to be apparent -- enclosure replies with "Name":"DriveBay1" via
ses (it does the same weirdness for sensors and other elements), and
make_dev_alias_v() does not like the double quotes.  Probably we need to
sanitize the input somewhere?

smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited

[Yuri]

Got this panic after booting GENERIC kernel:

panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 3
time = 1643658859
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00c7b20ae0
vpanic() at vpanic+0x17f/frame 0xfe00c7b20b30
panic() at panic+0x43/frame 0xfe00c7b20b90
malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00c7b20bb0
malloc_domainset() at malloc_domainset+0x36/frame 0xfe00c7b20c20
bounce_bus_dmamem_alloc() at bounce_bus_dmamem_alloc+0x5b/frame
0xfe00c7b20c50
os_dma_mem_alloc() at os_dma_mem_alloc+0xe3/frame 0xfe00c7b20c90
pqisrc_build_send_raid_request() at
pqisrc_build_send_raid_request+0x78/frame 0xfe00c7b20d30
pqisrc_write_current_time_to_host_wellness() at
pqisrc_write_current_time_to_host_wellness+0xff/frame
0xfe00c7b20df0os_wellness_periodic() at
os_wellness_periodic+0x1a/frame 0xfe00c7b20e10
softclock_call_cc() at softclock_call_cc+0x14d/frame 0xfe00c7b20ec0
softclock_thread() at softclock_thread+0xc6/frame 0xfe00c7b20ef0
fork_exit() at fork_exit+0x80/frame 0xfe00c7b20f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c7b20f30

The reason seems to be obvious enough, changing BUS_DMA_WAITOK to
BUS_DMA_NOWAIT in os_dma_mem_alloc() helps.

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Yuri]

Ed Maste wrote:
> The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and
> I propose removing it for FreeBSD 14. I know the CHERI folks have been
> using it but they plan to migrate away from it. It was broken for
> months before they fixed it, so I suspect nobody is using it on
> contemporary releases.
> 
> I have review D32707 (https://reviews.freebsd.org/D32707) open to add
> this deprecation notice to the man page:
>  The smbfs filesystem driver supports only the obsolete SMBv1 protocol.
>  smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not
>  present in FreeBSD 14 and above.  Users are advised to evaluate the
>  sysutils/fusefs-smbnetfs port instead.
> 
> A similar notice would be added to the smbutil and mount_smbfs man
> pages, and manu@ suggested having the userland utilities emit a
> warning when they are used.
> 
> I am interested in comments, objections, or reports that anyone is in
> fact using smbfs.

I thought I'd mention the SMB client in illumos which is originally
based on FreeBSD one, imported and enhanced by Apple, then imported by
Sun, and finally updated to support SMB2/SMB3 in illumos.  It has a lot
of CDDL code now, but as ZFS shows it's not really a stopper.

ISTR there is (was?) also an Apple SMB client (based on FreeBSD)
somewhere on their "opensource" site.

Just saying that there are other options if someone(TM) is interested in
doing the work.

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Yuri Tcherkasov]

Thanx very much

Цитирую "Alexander V. Chernikov" :


On 12 Sep 2021, at 11:51, Yuri Tcherkasov  wrote:

 ipfw nat 1 config ip XXX.XXX.XXX.xx reset unreg_only same_ports


Looks pretty close to https://reviews.freebsd.org/D23450  
<https://reviews.freebsd.org/D23450>


I guess rebuilding the ipfw(8) binary should help.



--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Yuri Tcherkasov]

The command is

root@gw:/home/tyv # ipfw nat 1 config ip XXX.XXX.XXX.xx reset  
unreg_only same_ports

ipfw nat 1 config ip 195.138.73.206 same_ports unreg_only reset
root@gw:/home/tyv #



Цитирую "Alexander V. Chernikov" :


On 12 Sep 2021, at 06:52, Yuri Tcherkasov  wrote:

Hi

I'm binary upgrade FreeBSD from 10.2 to 13.0

After upgrate all workin well, but I need add one more routing  
table. So add to

GENERIC kernel
You can add 'net.fibs=2' in the loader.conf, there is no need to  
recompile the kernel.

You can also set in runtime via sysctl.


options ROUTETABLES=2

and recompile it.
After normaly recompile can't configure ipfw nat with error

ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Could you share the particular command failing?



Returning original kernel instataling with upgrade resolve problem  
with nat but multiple route I can't use.


Anybody can help me?

Thanx!

--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua





--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Yuri Tcherkasov]

Thanx, i try.

Цитирую "Alexander V. Chernikov" :


On 12 Sep 2021, at 06:52, Yuri Tcherkasov  wrote:

Hi

I'm binary upgrade FreeBSD from 10.2 to 13.0

After upgrate all workin well, but I need add one more routing  
table. So add to

GENERIC kernel
You can add 'net.fibs=2' in the loader.conf, there is no need to  
recompile the kernel.

You can also set in runtime via sysctl.


options ROUTETABLES=2

and recompile it.
After normaly recompile can't configure ipfw nat with error

ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Could you share the particular command failing?



Returning original kernel instataling with upgrade resolve problem  
with nat but multiple route I can't use.


Anybody can help me?

Thanx!

--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua





--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua

Re: ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Yuri Tcherkasov]

Thanx, i try.


Цитирую "Alexander V. Chernikov" :


On 12 Sep 2021, at 06:52, Yuri Tcherkasov  wrote:

Hi

I'm binary upgrade FreeBSD from 10.2 to 13.0

After upgrate all workin well, but I need add one more routing  
table. So add to

GENERIC kernel
You can add 'net.fibs=2' in the loader.conf, there is no need to  
recompile the kernel.

You can also set in runtime via sysctl.


options ROUTETABLES=2

and recompile it.
After normaly recompile can't configure ipfw nat with error

ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Could you share the particular command failing?



Returning original kernel instataling with upgrade resolve problem  
with nat but multiple route I can't use.


Anybody can help me?

Thanx!

--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua





--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua

ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

[Yuri Tcherkasov]

Hi

I'm binary upgrade FreeBSD from 10.2 to 13.0

After upgrate all workin well, but I need add one more routing table.  
So add to

GENERIC kernel

options ROUTETABLES=2

and recompile it.
After normaly recompile can't configure ipfw nat with error

ipfw: setsockopt(IP_FW_NAT44_XCONFIG): Invalid argument

Returning original kernel instataling with upgrade resolve problem  
with nat but multiple route I can't use.


Anybody can help me?

Thanx!

--
--
Yuri Tcherkasov
E-Mail:  t...@uats.od.ua

Re: linking to git revisions in bugzilla

[Yuri Pankov]

Oleksandr Tymoshenko wrote:
> Kubilay Kocak (ko...@freebsd.org) wrote:
>> On 12/04/2021 9:02 am, Yuri Pankov wrote:
>>> While filing a bug, I noticed that the help only mentions svn revision 
>>> numbers, and "Preview" tab had no output when I tried putting "base 
>>> ", so I'm wondering how do you link to git revisions?
>>
>> We'll (bugmeister) be adding parsing support for it (along with a few 
>> other related auto-linking things)
>>
>> I'd encourage people to use " " (repo = src|doc|ports) 
>> where short hash is at least 8 chars in the meantime. Once parsing is 
>> added all previous references will be linked.
> 
> Links to git hashes should work now, please test and let us
> know if feature works as expected. As Michael mentioned - preview
> is a different matter, I'll try to look into it later.

Hi Oleksandr,

It seems to work except when the git hash starts with a digit, it then
tries to link to subversion revision using all available digits at the
start of the hash.  Or, at least, that's what I'm seeing in preview tab,
not sure if it has been fixed yet?
___
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: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)

[Yuri Pankov]

Mark Millard via freebsd-current wrote:
> Context:
> 
> # gpart show -pl da0
> =>   40  468862048da0  GPT  (224G)
>  40 532480  da0p1  efiboot0  (260M)
>  532520   2008 - free -  (1.0M)
>  534528   25165824  da0p2  swp12a  (12G)
>25700352   25165824  da0p4  swp12b  (12G)
>50866176  417994752  da0p3  zfs0  (199G)
>   468860928   1160 - free -  (580K)
> 
> There is just one pool: zroot and it is on zfs0 above.
> 
> # zpool list -p
> NAME   SIZEALLOC  FREE  CKPOINT  EXPANDSZ   FRAG
> CAP  DEDUPHEALTH  ALTROOT
> zroot  213674622976  71075655680  142598967296- - 28 
> 33   1.00ONLINE  -
> 
> So FREE: 142_598_967_296
> (using _ to make it more readable)
> 
> # zfs list -p zroot 
> NAME  USED AVAIL REFER  MOUNTPOINT
> zroot  71073697792  135923593216 98304  /zroot
> 
> So AVAIL: 135_923_593_216
> 
> FREE-AVAIL == 6_675_374_080
> 
> 
> 
> The questions:
> 
> Is this sort of unavailable pool-free-space normal?
> Is this some sort of expected overhead that just is
> not explicitly reported? Possibly a "FRAG"
> consequence?

>From zpoolprops(8):

freeThe amount of free space available in the pool.  By contrast,
the zfs(8) available property describes how much new data can be
written to ZFS filesystems/volumes.  The zpool free property is
not generally useful for this purpose, and can be substantially
more than the zfs available space. This discrepancy is due to
several factors, including raidz parity; zfs reservation, quota,
refreservation, and refquota properties; and space set aside by
spa_slop_shift (see zfs-module-parameters(5) for more
information).
___
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"

git magic in contrib/bc

[Yuri Pankov]

Not sure if it's just me, but I'm seeing a bit of git weirdness in
contrib/bc:

$ cd freebsd-src
$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
$ cd ..
$ cp -a freebsd-src freebsd-src-copy
$ cd freebsd-src-copy
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
modified:   contrib/bc/bc.vcxproj
modified:   contrib/bc/bc.vcxproj.filters
modified:   contrib/bc/bcl.vcxproj
modified:   contrib/bc/bcl.vcxproj.filters

no changes added to commit (use "git add" and/or "git commit -a")

I can't figure what exactly changed in these files, diff (normal
command, not git diff) does not show any differences, they are not symlinks.

This happens with clean clones from git.freebsd.org,
gitrepo.freebsd.org, and github; it did not happen previously (not sure
when it started though) -- I was usually just copying the whole tree
into ~/ws/.

Any hints?
___
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: catch-all daemon.info entry in syslog.conf is a bit unhelpful

[Yuri Pankov]

Yuri Pankov wrote:
> I understand it's been quite some time since it was added, but I have
> been bitten by it just now.  I am adding per-daemon .conf files for
> ports in /usr/local/etc/syslog.d/ and noticed that none of them were
> working.
> 
> An example entry is:
> 
> $ cat /usr/local/etc/syslog.d/dhcpd.conf
> !dhcpd
> *.* /var/log/dhcpd.log
> 
> Then I noticed the daemon.info entry in /etc/syslog.conf and had to
> workaround it like below:
> 
> !-dhcpd
> daemon.info /var/log/daemon.log
> !+dhcpd
> 
> Given the above, I'm wondering if we could move the daemon.info entry to
> the bottom *after* we read the include dirs, so it would only select
> everything that is not handled already?

Or, better yet, ignore this; I'm not sure what exactly I was doing
wrong, but after I sent the mail it all started working as it should
(happens all the time for me), sorry for the noise.
___
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"

catch-all daemon.info entry in syslog.conf is a bit unhelpful

[Yuri Pankov]

I understand it's been quite some time since it was added, but I have
been bitten by it just now.  I am adding per-daemon .conf files for
ports in /usr/local/etc/syslog.d/ and noticed that none of them were
working.

An example entry is:

$ cat /usr/local/etc/syslog.d/dhcpd.conf
!dhcpd
*.* /var/log/dhcpd.log

Then I noticed the daemon.info entry in /etc/syslog.conf and had to
workaround it like below:

!-dhcpd
daemon.info /var/log/daemon.log
!+dhcpd

Given the above, I'm wondering if we could move the daemon.info entry to
the bottom *after* we read the include dirs, so it would only select
everything that is not handled already?
___
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: Trying to build Current

[Yuri Pankov]

Willem Jan Withagen via freebsd-current wrote:
> On 15-4-2021 11:47, Gary Jennejohn wrote:
>> On Thu, 15 Apr 2021 10:51:39 +0200
>> Willem Jan Withagen via freebsd-current 
>> wrote:
>>
>>> Hi,
>>>
>>> I actually went completely back to the basic setup with directories
>>> /usr/src and /usr/obj
>>> But even then I do not manage to buildworld.
>>> The process keeps bumping into missing bsm/audit.
>>>
>>> First case was when it tried to build the 64bit libc.
>>> I copied the bsm directory into
>>>   __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/
>>>
>>> Which allowed it to continue.
>>> But then a bit further on it halts again in 32bit libc.
>>> Whcih I could fix the same way.
>>>
>>> --- fts.o ---
>>> In file included from /usr/src/lib/libc/gen/fts.c:40:
>>> In file included from
>>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38:
>>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10:
>>>
>>> fatal error: 'bsm/audit.h' file not found
>>> #include 
>>>    ^
>>>
>>> Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing
>>> 'make world'
>>>
>>> So why is this include file missing?
>>>
>> Try running make includes first. This step is missing because you are NOT
>> doing a buildworld.
>>
> Well actual the commands were:
> 
> rm -rf /usr/src /usr/obj
> mkdir -p /usr/src /usr/obj
> cd /usr/src
> git clone https://git.freebsd.org/src.git .
> make -j16 buildworld
> 
> But I'll give it a shot anyways.

Anything in /etc/make.conf and /etc/src.conf?
___
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"

"ahci0: AHCI v1.30 with 6 6Gbps ports" while only 2 of those are SATA3

[Yuri Pankov]

That is on somewhat older Supermicro X9DRI-LN4F+ board:

ahci0:  port
0x9050-0x9057,0x9040-0x9043,0x9030-0x9037,0x9020-0x9023,0x9000-0x901f
mem 0xdfa21000-0xdfa217ff irq 18 at device 31.2 numa-domain 0 on pci0
ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported

and then I was confused by messages about SATA3 drives connected to
ports 2-5 (see the "transfers" line):

ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1:  ACS-3 ATA SATA 3.x device
ada1: Serial Number WD-WX32D7088CCV
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 3815447MB (7814037168 512 byte sectors)

Checking the board manual made it clear than only ports 0-1 are SATA3,
and 2-5 are indeed SATA2.  While the issue is purely cosmetic, I wonder
if it's possible to print real port speeds for the controller, i.e. if
this information is available to driver?
___
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"

linking to git revisions in bugzilla

[Yuri Pankov]

While filing a bug, I noticed that the help only mentions svn revision numbers, 
and "Preview" tab had no output when I tried putting "base ", 
so I'm wondering how do you link to git revisions?
___
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: ZFS not mount at boot

[Yuri Pankov]

beepc.ch wrote:
> Dear list,
> 
> I've freshly installed FreeBSD 13-RC5 following this wiki for ZFS manual
> configuration:
> 
> https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
> 
> After restart, the ZFS datasets aren't mount at boot:
> 
> # mount
> zroot/ROOT/default on / (zfs, local, nfsv4acls)
> devfs on /dev (devfs)
> 
> Doing a zfs mount -a, then everything is there:
> zroot/ROOT/default on / (zfs, local, nfsv4acls)
> devfs on /dev (devfs)
> zroot/tmp on /tmp (zfs, local, nosuid, nfsv4acls)
> zroot on /zroot (zfs, local, nfsv4acls)
> zroot/var/log on /var/log (zfs, local, noexec, nosuid, nfsv4acls)
> zroot/usr/ports on /usr/ports (zfs, local, nosuid, nfsv4acls)
> zroot/usr/home on /usr/home (zfs, local, nfsv4acls)
> zroot/var/mail on /var/mail (zfs, local, noexec, nosuid, nfsv4acls)
> zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
> zroot/var/crash on /var/crash (zfs, local, noexec, nosuid, nfsv4acls)
> zroot/usr/obj on /usr/obj (zfs, local, nfsv4acls)
> zroot/var/tmp on /var/tmp (zfs, local, nosuid, nfsv4acls)
> zroot/var/audit on /var/audit (zfs, local, noexec, nosuid, nfsv4acls)
> zroot/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noexec,
> nosuid, nfsv4acls)
> zroot/usr/ports/packages on /usr/ports/packages (zfs, local, noexec,
> nosuid, nfsv4acls)
> 
> - in /boot/loader.conf
> zfs_load="YES"
> 
> - in /etc/rc.conf:
> zfs_enabled="YES"

If this is exactly what you have in rc.conf, then it's the problem -- it
should be "enable", not "enabled".

> I don't know what is missing.

___
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: no time selection screen in installer anymore

[Yuri Pankov]

Yuri Pankov wrote:
> Installing from
> FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, I
> noticed that there's no time selection screen anymore; TZ is there, date
> is there, and only time is missing.
> 
> Not that I miss it much, but it does not seem to be removed from source,
> so I'm wondering if it's recent dialog update that broke it?

Apparently dialog does not like the height of 2 anymore here (while it
still works for --calendar):

usr.sbin/bsdinstall/scripts/time:

TIME=$(dialog --backtitle 'FreeBSD Installer' \
--title 'Time & Date' \
--ok-label 'Set Time' \
--cancel-label 'Skip' \
--defaultno \
--time-format '%H%M.%S' \
--timebox '' 2 40 \
2>&1 1>&3) && date $TIME

We could use a height of 0 for minimal possible size.
___
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: [Bug 254395] bsdinstall: fail script install after BETA3

[Yuri Pankov]

Chris wrote:
> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>
>> Nathan Whitehorn  changed:
>>
>>    What    |Removed |Added
>> 
>>
>>    Severity|Affects Only Me |Affects Some People
>>  CC|    |i...@freebsd.org
>>    Priority|--- |Normal
>>
>> --- Comment #6 from Nathan Whitehorn  ---
>> Thanks for the suggestion about the documentation -- I've updated the
>> man page.
>>
>> The core problem here is that our tar can't extract archives to FAT32
>> with
>> default options, since it treats inability to set modification time as
>> a fatal
>> error and FAT32 doesn't let you do that on the root directory. As
>> such, any
>> file in the release tarballs can't be extracted to FAT32. For interactive
>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>> libarchive, solves this by ignoring ctime/mtime errors.
>>
>> Some extra commentary on solutions, so it can be in one place.
>> Possibilities
>> are:
>>
>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>> base.txz, solving this issue, but will result in it not being in
>> mtree. It will
>> also leave in place an identical bug that will break scripted
>> installation on
>> bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.
>>
>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>> like the
>> interactive installer uses. This has the difficulty that the patch is
>> hacky and
>> would have to go through upstream.
>>
>> 3. We go back to using distextract for scripted installations as well as
>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>> This
>> fixes this issue but will result in installation failures for scripted
>> installs
>> without a controlling tty. (It will also add nice progress bars to
>> scripted
>> installs).
>>
>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>> afterward. This is incredibly hacky and otherwise essentially
>> functionally
>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>> functional
>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>> broken.
>>
>> 5. We patch the file system driver to (pretend to) allow setting times
>> on the
>> mount point. I don't want to do this, since I don't want to solve this
>> in the
>> kernel at RC3 and I don't like it pretending to do things it can't do.
> 
>  6. (my favorite) do NOT require that the efi/ partition be in strictly a
>  fat32 format. I mean fat32 is not strictly required as the format for
> the efi
>  partition. It is simply _assumed_ to be the required format and as
> such, the
>  one used in so many cases.

Wrong, see "13.3 File System Format" in UEFI specification.

> Whould it actually be that much harder to use ffs/ufs?
> 
> You asked. ;-)
> 
>>
>> 
>>
>> Of these, 1, 3, and 4 are quite easy to implement, but all have some
>> downside.
>> My temptation is to do 4 for 13.0, since it will definitely work but
>> is just
>> lame, then either do #2 or a variant on #3 where distextract notices
>> there is
>> no tty and doesn't try to set up a dialog as a longer-term fix in
>> HEAD. Any
>> thoughts?

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

no time selection screen in installer anymore

[Yuri Pankov]

Installing from
FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, I
noticed that there's no time selection screen anymore; TZ is there, date
is there, and only time is missing.

Not that I miss it much, but it does not seem to be removed from source,
so I'm wondering if it's recent dialog update that broke it?
___
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: panic: malloc(M_WAITOK) with sleeping prohibited

[Yuri Pankov]

Yuri Pankov wrote:
> H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using
> FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso.

Somehow I missed that it was already reported (a lot) and seems to be
already fixed with
FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, sorry
for the noise.
___
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"

panic: malloc(M_WAITOK) with sleeping prohibited

[Yuri Pankov]

H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using
FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso.

Root mount waiting for: usbus0
ugen0.4:  at usbus0
umass0 numa-domain 0 on uhub2
umass0: 
on usbus0
umass0: SCSI over Bulk-Only; quirks = 0xc101
umass0:7:0: Attached to scbus7
umass1 numa-domain 0 on uhub2
umass1: 
on usbus0
umass1: 8070i (ATAPI) over Bulk-Only; quirks = 0xc101
umass1:8:1: Attached to scbus8
panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 37
time = 9
KDB: stack backtrace:
db_trace_self_wrapper()
vpanic()
malloc_dbg()
malloc()
disk_alloc()
cdregister()
cam_periph_alloc()
cdasync()
xpt_async_process_dev()
xpt_async_process()
xpt_done_process()
xpt_done_td()
fork_exit()
fork_trampoline()
--- trap 0, rip = 0, rsp = 0, rbp =0 ---
KDB: enter: panic
[ thread pid 49 tid 100383 ]
___
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"

loader/boot fonts are painfully small (again)

[Yuri Pankov]

Lenovo P51 laptop, 15'' 4k (3840x2160) display.

Booting from the latest available current snapshot (20210107), fonts
were at least readable; updating to the latest bits (manually installing
new loader as well) made them really small -- terminal size reported by
stty is 480x135.

I have also noticed large delays between different loader screens,
probably caused by very slow screen blanking given the terminal size?
___
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: regression in /etc/rc.d/linux

[Yuri Pankov]

Sergey V. Dyatko wrote:

Hi,

Subj was introduced in  e40787f900f3c262d5134d342e5a16757dd2193c

compat.linux.emul_path isn't defined before kldload`ing linux/linux64 kernel.


Looks like it's already fixed:

https://cgit.freebsd.org/src/commit/?id=07cac176fba947381c8111b8e02e8067e7fa542a
___
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: Boot panic on Lenovo P50s since r367998

[Yuri Pankov]

Yuri Pankov wrote:

Tomoaki AOKI wrote:

On Thu, 24 Dec 2020 10:34:49 +0100
Marc Veldman  wrote:


Hello,

since r367998 my Lenovo P50s panics on boot:

mmc0: detached
panic: Bad link elm 0xf80003a73300 next->prep != elm
cupid=3
time=2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0x8299a9c0

vpanic() at vpanic+0x181/frame 0x8299aa10
panic() at panic+0x43/frame 0x8299aa70
config_intrhook_disestablish() at 
config_intrhook_disestablish+0xf3/frame 0x8299aa90
config_intrhook_oneshot_func() at 
config_intrhook_oneshot_func+0x18/frame 0x8299aab0
run_interrupt_driven_config_hooks() at 
run_interrupt_driven_config_hooks+0x77/frame 0x8299aad0
boot_run_interrupt_driven_config_hooks() at 
boot_run_interrupt_driven_config_hooks+0x1f/frame 0x8299ab60

mi_startup() at mi_startup+0xec/frame 0x8299abb0
btext() at btext+0x2c
KDB: enter: panic
[thread pid 0 tid 10]
Stopped at kdb_enter+0x37: movq $0,0x10ada46(%rip)

If needed, I can test patches

Dmesg (with r367977 kernel)

---<>---
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
 root@devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.0-0-g176249bd673)

WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 1920x1080
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
   
Features=0xbfebfbff 

   
Features2=0x7ffafbbf 


   AMD Features=0x2c100800
   AMD Features2=0x121
   Structured Extended 
Features=0x29c67af 


   Structured Extended Features3=0x9c00
   XSAVE Features=0xf
   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
   TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16421109760 (15660 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0  irqs 0-119
Launching APs: 1 3 2
Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
random: entropy device external interface
WARNING: Device "kbd" is Giant locked and may be deleted before 
FreeBSD 13.0.

kbd1 at kbdmux0
000.45 [4346] netmap_init   netmap: loaded module
[ath_hal] loaded
nexus0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.00s
cryptosoft0: 
aesni0: 
acpi0: 
acpi_ec0:  port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
cpu0:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 2400 Hz quality 950
Event timer "HPET" frequency 2400 Hz quality 550
Event timer "HPET1" frequency 2400 Hz quality 440
Event timer "HPET2" frequency 2400 Hz quality 440
Event timer "HPET3" frequency 2400 Hz quality 440
Event timer "HPET4" frequency 2400 Hz quality 440
atrtc0:  port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0xe000-0xe03f mem 
0xf200-0xf2ff,0xd000-0xdfff irq 16 at device 2.0 on pci0

vgapci0: Boot video device
xhci0:  mem 
0xf422-0xf422 at device 20.0 on pci0

xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0:  at device 22.0 (no driver attached)
ahci0:  port 
0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 
0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at 
device 23.0 on pci0

ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
ahcich1:  at channel 1 on ahci0
pcib1:  at device 28.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
pcib2:  at device 28.2 on pci0
pci2:  on pcib2
pci2:  at device 0.0 (no driver attached)
pcib3:  at device 29.0 on pci0
pci3:  on pcib3
vgapci1:  port 0xd000-0xd07f mem 
0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at 
device 0.0 on pci3

isab0:  at dev

Re: Boot panic on Lenovo P50s since r367998

[Yuri Pankov]

Tomoaki AOKI wrote:

On Thu, 24 Dec 2020 10:34:49 +0100
Marc Veldman  wrote:


Hello,

since r367998 my Lenovo P50s panics on boot:

mmc0: detached
panic: Bad link elm 0xf80003a73300 next->prep != elm
cupid=3
time=2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8299a9c0
vpanic() at vpanic+0x181/frame 0x8299aa10
panic() at panic+0x43/frame 0x8299aa70
config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 
0x8299aa90
config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 
0x8299aab0
run_interrupt_driven_config_hooks() at 
run_interrupt_driven_config_hooks+0x77/frame 0x8299aad0
boot_run_interrupt_driven_config_hooks() at 
boot_run_interrupt_driven_config_hooks+0x1f/frame 0x8299ab60
mi_startup() at mi_startup+0xec/frame 0x8299abb0
btext() at btext+0x2c
KDB: enter: panic
[thread pid 0 tid 10]
Stopped at kdb_enter+0x37: movq $0,0x10ada46(%rip)

If needed, I can test patches

Dmesg (with r367977 kernel)

---<>---
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
 root@devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.0-0-g176249bd673)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 1920x1080
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
   
Features=0xbfebfbff
   
Features2=0x7ffafbbf
   AMD Features=0x2c100800
   AMD Features2=0x121
   Structured Extended 
Features=0x29c67af
   Structured Extended Features3=0x9c00
   XSAVE Features=0xf
   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
   TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16421109760 (15660 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0  irqs 0-119
Launching APs: 1 3 2
Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
random: entropy device external interface
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
kbd1 at kbdmux0
000.45 [4346] netmap_init   netmap: loaded module
[ath_hal] loaded
nexus0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.00s
cryptosoft0: 
aesni0: 
acpi0: 
acpi_ec0:  port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
cpu0:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 2400 Hz quality 950
Event timer "HPET" frequency 2400 Hz quality 550
Event timer "HPET1" frequency 2400 Hz quality 440
Event timer "HPET2" frequency 2400 Hz quality 440
Event timer "HPET3" frequency 2400 Hz quality 440
Event timer "HPET4" frequency 2400 Hz quality 440
atrtc0:  port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0xe000-0xe03f mem 
0xf200-0xf2ff,0xd000-0xdfff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
xhci0:  mem 0xf422-0xf422 at 
device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0:  at device 22.0 (no driver attached)
ahci0:  port 
0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 
0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on 
pci0
ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
ahcich1:  at channel 1 on ahci0
pcib1:  at device 28.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
pcib2:  at device 28.2 on pci0
pci2:  on pcib2
pci2:  at device 0.0 (no driver attached)
pcib3:  at device 29.0 on pci0
pci3:  on pcib3
vgapci1:  port 0xd000-0xd07f mem 
0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at device 0.0 on 
pci3
isab0:  at device 31.0 on pci0
isa0:  on isab0
pci0:  at device 31.2 (no driver attached)
hdac0:  mem 
0xf424-0xf4243fff,0xf423-0xf423 at device 31.3 on pci0
em0:  mem 0xf420-0xf421 at device 
31.6 

Re: Boot panic on Lenovo P50s since r367998

[Yuri Pankov]

Marc Veldman wrote:

Hello,

since r367998 my Lenovo P50s panics on boot:

mmc0: detached
panic: Bad link elm 0xf80003a73300 next->prep != elm
cupid=3
time=2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8299a9c0
vpanic() at vpanic+0x181/frame 0x8299aa10
panic() at panic+0x43/frame 0x8299aa70
config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 
0x8299aa90
config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 
0x8299aab0
run_interrupt_driven_config_hooks() at 
run_interrupt_driven_config_hooks+0x77/frame 0x8299aad0
boot_run_interrupt_driven_config_hooks() at 
boot_run_interrupt_driven_config_hooks+0x1f/frame 0x8299ab60
mi_startup() at mi_startup+0xec/frame 0x8299abb0
btext() at btext+0x2c
KDB: enter: panic
[thread pid 0 tid 10]
Stopped at kdb_enter+0x37: movq $0,0x10ada46(%rip)


r367998 adds rtsx driver for card reader, seems to work for me on P51 
(as in "detected and does not panic", I don't have any cards around to 
really test it):


rtsx0@pci0:63:0:0:	class=0xff rev=0x01 hdr=0x00 vendor=0x10ec 
device=0x525a subvendor=0x17aa subdevice=0x224d

vendor  = 'Realtek Semiconductor Co., Ltd.'
device  = 'RTS525A PCI Express Card Reader'

To confirm the issue is indeed in rtsx, does disabling the card reader 
in bios help?  If it does, what is the device exactly (`pciconf -lv` 
when booted on pre-r367998)?

___
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: referencing one commit in another for git

[Yuri Pankov]

Warner Losh wrote:

On Wed, Dec 23, 2020 at 6:22 PM Jan Beich  wrote:


Warner Losh  writes:


On Wed, Dec 23, 2020, 3:21 PM Alan Somers  wrote:


On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem 

wrote:



Hi,

So I just did my first git commit. Pretty scary, but it looks ok.

Now, how do I reference one commit in another related
commit's log?

By the long winded hash or ??

I'm not sure if I should ask here or on the git mailing list,
but I figured this isn't a technical git question...

Thanks for any help with this, rick



Yeah, you should use the full hash.  For temporary references, like

during

a code review, you can use the first "several" digits of the hash.

  For a

project of FreeBSD's size, "several" is probably 11-13.  But in

permanent

contexts, like commit logs, you should use the full hash.  When somebody
views the commit on a platform like Github, Github will automatically

turn

it into a hyperlink, and display only the first "several" digits.




For MFCs we are recommending the first 11. I think this will likely

suffice

and matches the git client behavior.


Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.



I've updated to 12. That sounds like a good number of digits...Thanks.


I think the common way is to use `git rev-parse --short `, 
though we are likely to recommend increasing the core.abbrev value which 
sets the minimum length of unique prefix (default is 4).

___
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: installation on pvscsi fails with "The request was too large for this host"

[Yuri Pankov]

Andriy Gapon wrote:

On 17/12/2020 07:02, Yuri Pankov wrote:

Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs
with pvscsi fails on bootloader step, and the following is in dmesg:

pvscsi0: pvscsi_execute_ccb error 27
pvscsi0: pvscsi_execute_ccb error 27
(da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
(da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
(da0:pvscsi0:0:0:0): Error 22, Unretryable error
(da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
(da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
(da0:pvscsi0:0:0:0): Error 22, Unretryable error

That is the first I'm trying installing on pvscsi since it was integrated, so no
idea if it worked previously.  If yes, I have not tried to bisect this yet
hoping that it could be identified as related to any of the recent changes.

The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks.


Not an expert in this areas, but that command tried to transfer 0x400 / 1024
blocks, which is 512KB of data.
Could it be that the problem is revealed by the MAXPHYS increase?
There might be a bug in pvscsi where it does not respect or correctly advertise
some limit.  There could be a similar issue with VMware itself (its emulation of
a disk / target).


Yes, it looks like reverting MAXPHYS back to 128K made the problem 
disappear, successfully installed VM from resulting cdrom image.

___
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: acpi_wmi noisy without EC

[Yuri Pankov]

Yuri Pankov wrote:

On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:

On 2020-11-17 15:29, Yuri Pankov wrote:

On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:

On 2020-11-17 10:57, Vladimir Kondratyev wrote:

On 2020-11-17 03:00, Yuri Pankov wrote:

I have started seeing the following on boot since some time:

acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6

Likely following this commit:

commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev 
Date:   Sat Oct 31 22:19:39 2020 +

 acpi_wmi(4): Add ACPI_PNP_INFO

While the reason is obvious -- there's no EC in this system (Gigabyte
X299X AORUS MASTER desktop motherboard), at least searching the
`acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
looks like "something is broken" when first noticed.  I wonder if we
could/should handle this gracefully -- no EC, do nothing, simply exit?


Following patch should ignore missing EC like Linux does. Could you
test it?

diff --git a/sys/dev/acpi_support/acpi_wmi.c
b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
  if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
  == NULL)
  device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status =
AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
  ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
  device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
  AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
ACPI_PHYSICAL_ADDRESS address,
  return (AE_BAD_PARAMETER);
  if (address + (width / 8) - 1 > 0xFF)
  return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
  if (function == ACPI_READ)
  *value = 0;
  ec_addr = address;


@#@##! Web client ate all the tabs.

Patch is in attachment.


Output changed, though it's still somewhat noisy -- I guess there
isn't a way to NOT report the device that we are not going to attach
to, or do that e.g. only for verbose boot?

acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
object (Buffer) (20201113/nsarguments-361)
acpi_wmi1:  on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2:  on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3:  on acpi0
acpi_wmi3: cannot find EC device


acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
in OpRegion handler.
WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
successfully attached to 4 nodes.


Oh great, I misunderstood then.  And indeed, sysctl -b dev.acpi_wmi.0.bmof | 
bmf2mof provides some interesting information.  All other 3 instances do not 
though.  In any case, it seems to work now.


Verbosity can be reduced with attached patch if current level is too
high for you.


Works for me both ways, I simply had the wrong impression that if we don't have 
EC, we can't attach at all.


Could you commit this, or is it incomplete fix?
___
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"

installation on pvscsi fails with "The request was too large for this host"

[Yuri Pankov]

Trying to install latest snapshot (20201210) on a VMware 
ESXi/Workstation VMs with pvscsi fails on bootloader step, and the 
following is in dmesg:


pvscsi0: pvscsi_execute_ccb error 27
pvscsi0: pvscsi_execute_ccb error 27
(da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
(da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
(da0:pvscsi0:0:0:0): Error 22, Unretryable error
(da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
(da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
(da0:pvscsi0:0:0:0): Error 22, Unretryable error

That is the first I'm trying installing on pvscsi since it was 
integrated, so no idea if it worked previously.  If yes, I have not 
tried to bisect this yet hoping that it could be identified as related 
to any of the recent changes.


The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks.
___
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: port build fails with missing sys/smr_types.h

[Yuri Pankov]

Alan Somers wrote:

On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli  wrote:


Hi

I'm trying to fix the build of qemu-utils but am seeing failures on
CURRENT (13.0-HEAD-9e082d278b9) like:

In file included from util/oslib-posix.c:50:
In file included from /usr/include/sys/user.h:51:
In file included from /usr/include/sys/proc.h:50:
/usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not
found
#include 
  ^

# uname -a
FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
00:09:50 PST 2020
root@freebsd
:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
  amd64
# ls -l /usr/include/sys/*smr*
-r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
-r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h

So it appears the file is missing. Any ideas?

--chuck



That file doesn't get installed into /usr/include, but it exists in
/usr/src.  A few ports need /usr/src.  See  devel/py-libzfs/Makefile for an
example of how to find it.


But it's included from the header that *is* in /usr/include/, not 
directly by external code.  Should not such dependencies all be in 
/usr/include/?

___
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: acpi_wmi noisy without EC

[Yuri Pankov]

On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
> On 2020-11-17 15:29, Yuri Pankov wrote:
> > On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
> >> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> >> > On 2020-11-17 03:00, Yuri Pankov wrote:
> >> >> I have started seeing the following on boot since some time:
> >> >>
> >> >> acpi_wmi0:  on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0:  on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0:  on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0:  on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >>
> >> >> Likely following this commit:
> >> >>
> >> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
> >> >> Author: Vladimir Kondratyev 
> >> >> Date:   Sat Oct 31 22:19:39 2020 +
> >> >>
> >> >> acpi_wmi(4): Add ACPI_PNP_INFO
> >> >>
> >> >> While the reason is obvious -- there's no EC in this system (Gigabyte
> >> >> X299X AORUS MASTER desktop motherboard), at least searching the
> >> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
> >> >> looks like "something is broken" when first noticed.  I wonder if we
> >> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
> >> >
> >> > Following patch should ignore missing EC like Linux does. Could you
> >> > test it?
> >> >
> >> > diff --git a/sys/dev/acpi_support/acpi_wmi.c
> >> > b/sys/dev/acpi_support/acpi_wmi.c
> >> > index 379cfd1705f1..efae96cdcc9a 100644
> >> > --- a/sys/dev/acpi_support/acpi_wmi.c
> >> > +++ b/sys/dev/acpi_support/acpi_wmi.c
> >> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> >> >  if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> >> >  == NULL)
> >> >  device_printf(dev, "cannot find EC device\n");
> >> > - else if (ACPI_FAILURE((status =
> >> > AcpiInstallNotifyHandler(sc->wmi_handle,
> >> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> >> >  ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> >> >  device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> >> >  AcpiFormatException(status));
> >> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> >> > ACPI_PHYSICAL_ADDRESS address,
> >> >  return (AE_BAD_PARAMETER);
> >> >  if (address + (width / 8) - 1 > 0xFF)
> >> >  return (AE_BAD_ADDRESS);
> >> > + if (sc->ec_dev == NULL)
> >> > + return (AE_NOT_FOUND);
> >> >  if (function == ACPI_READ)
> >> >  *value = 0;
> >> >  ec_addr = address;
> >> 
> >> @#@##! Web client ate all the tabs.
> >> 
> >> Patch is in attachment.
> > 
> > Output changed, though it's still somewhat noisy -- I guess there
> > isn't a way to NOT report the device that we are not going to attach
> > to, or do that e.g. only for verbose boot?
> > 
> > acpi_wmi0:  on acpi0
> > acpi_wmi0: cannot find EC device
> > acpi_wmi0: Embedded MOF found
> > ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
> > object (Buffer) (20201113/nsarguments-361)
> > acpi_wmi1:  on acpi0
> > acpi_wmi1: cannot find EC device
> > acpi_wmi2:  on acpi0
> > acpi_wmi2: cannot find EC device
> > acpi_wmi3:  on acpi0
> > acpi_wmi3: cannot find EC device
> 
> acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it 
> in OpRegion handler.
> WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has 
> successfully attached to 4 nodes.

Oh great, I misunderstood then.  And indeed, sysctl -b dev.acpi_wmi.0.bmof | 
bmf2mof provides some interesting information.  All other 3 instances do not 
though.  In any case, it seems to work now.

> Verbosity can be reduced with attached patch if current level is too 
> high for you.

Works for me both ways, I simply had the wrong impression that if we don't have 
EC, we can't attach at all.
___
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: acpi_wmi noisy without EC

[Yuri Pankov]

On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> > On 2020-11-17 03:00, Yuri Pankov wrote:
> >> I have started seeing the following on boot since some time:
> >> 
> >> acpi_wmi0:  on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0:  on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0:  on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0:  on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> 
> >> Likely following this commit:
> >> 
> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
> >> Author: Vladimir Kondratyev 
> >> Date:   Sat Oct 31 22:19:39 2020 +
> >> 
> >> acpi_wmi(4): Add ACPI_PNP_INFO
> >> 
> >> While the reason is obvious -- there's no EC in this system (Gigabyte
> >> X299X AORUS MASTER desktop motherboard), at least searching the
> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
> >> looks like "something is broken" when first noticed.  I wonder if we
> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
> > 
> > Following patch should ignore missing EC like Linux does. Could you 
> > test it?
> > 
> > diff --git a/sys/dev/acpi_support/acpi_wmi.c 
> > b/sys/dev/acpi_support/acpi_wmi.c
> > index 379cfd1705f1..efae96cdcc9a 100644
> > --- a/sys/dev/acpi_support/acpi_wmi.c
> > +++ b/sys/dev/acpi_support/acpi_wmi.c
> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> >  if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> >  == NULL)
> >  device_printf(dev, "cannot find EC device\n");
> > - else if (ACPI_FAILURE((status = 
> > AcpiInstallNotifyHandler(sc->wmi_handle,
> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> >  ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> >  device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> >  AcpiFormatException(status));
> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> > ACPI_PHYSICAL_ADDRESS address,
> >  return (AE_BAD_PARAMETER);
> >  if (address + (width / 8) - 1 > 0xFF)
> >  return (AE_BAD_ADDRESS);
> > + if (sc->ec_dev == NULL)
> > + return (AE_NOT_FOUND);
> >  if (function == ACPI_READ)
> >  *value = 0;
> >  ec_addr = address;
> 
> @#@##! Web client ate all the tabs.
> 
> Patch is in attachment.

Output changed, though it's still somewhat noisy -- I guess there isn't a way 
to NOT report the device that we are not going to attach to, or do that e.g. 
only for verbose boot?

acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI object 
(Buffer) (20201113/nsarguments-361)
acpi_wmi1:  on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2:  on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3:  on acpi0
acpi_wmi3: cannot find EC device
___
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"

acpi_wmi noisy without EC

[Yuri Pankov]

I have started seeing the following on boot since some time:

acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6

Likely following this commit:

commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev 
Date:   Sat Oct 31 22:19:39 2020 +

acpi_wmi(4): Add ACPI_PNP_INFO

While the reason is obvious -- there's no EC in this system (Gigabyte X299X 
AORUS MASTER desktop motherboard), at least searching the `acpidump -dt` output 
doesn't show any PNP0C09 entries -- it certainly looks like "something is 
broken" when first noticed.  I wonder if we could/should handle this gracefully 
-- no EC, do nothing, simply exit?
___
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: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR

[Yuri Pankov]

driesm.michi...@gmail.com wrote:

I just want to add a "me to" here.

With a recent upgrade of CURRENT on my laptop, these error messages started
popping up.
Possibly not really harming anything under the hood though.


Looks like r365029 fixed it for me, and even ubt0 is back happily 
spamming console with netgraph warnings; didn't notice its absence as 
I'm not using bluetooth at the moment.



-Original Message-
From: owner-freebsd-curr...@freebsd.org  On Behalf Of Yuri Pankov
Sent: Thursday, 27 August 2020 21:18
To: bob prohaska 
Cc: curr...@freebsd.org
Subject: Re: usbd_setup_device_desc: getting device descriptor at addr 6
failed, USB_ERR_IOERROR

bob prohaska wrote:

On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote:

Another issue that I started seeing lately, didn't try finding out
when exactly in case someone knows what it's about:

Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed,
USB_ERR_IOERROR


[details snipped]


So far not seeing any ill effects from this, i.e. I can connect USB
HDD to these ports, and it's successfully detected.


If it's convenient, connecting a USB-serial adapter and rebooting
might be interesting. I'm having trouble with FT232 obstructing disk
detection in some cases and self-disconnecting in others on a Pi3B.


Don't have one.  It is "desktop" PC, so the only USB devices I have/need

are

keyboard/mouse and memsticks.

___
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: panic in range_tree_seg64_compare()

[Yuri Pankov]

Matthew Macy wrote:

On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov  wrote:


Yet another issue I'm seeing after last update (currently running
r364870), hit it 2 times today:

Fatal trap 12: page fault while in kernel mode
cpuid = 19; apic id = 0d
fault virtual address   = 0xf819e2ecdc40
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x8277fa64
stack pointer   = 0x28:0xfe01f9ff2d90
frame pointer   = 0x28:0xfe01f9ff2d90
code segment= base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 48792 (blk-3:0-0)
trap number = 12
panic: page fault
cpuid = 19
time = 1598577675
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe01f9ff2a40
vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
panic() at panic+0x43/frame 0xfe01f9ff2af0
trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
--- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
0xfe01f9ff2d90 ---
range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
0xfe01f9ff2d90
zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30
range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
0xfe01f9ff3030
dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
0xfe01f9ff3180
g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
physio() at physio+0x4f8/frame 0xfe01f9ff3270
devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
--- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
Uptime: 4h13m43s





Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
for bhyve VM.  Anything known?


Not really. A reproduction scenario would be very helpful. This was
seen once by someone at iX - I committed some additional asserts to
the truenas tree, but haven't heard further.

+++ b/module/zfs/dbuf.c
@@ -3192,7 +3192,7 @@
dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
  * scheduled its write with its buffer, we must
  * disassociate by replacing the frontend.
  */
-   ASSERT(db->db_state & (DB_READ|DB_PARTIAL));
+   ASSERT3U(db->db_state, &, (DB_READ|DB_PARTIAL));
 ASSERT3U(db->db_dirtycnt, ==, 1);
 dbuf_dirty_set_data(dds);
 } else {
@@ -3238,18 +3238,24 @@ dbuf_dirty_record_create_leaf(dbuf_dirty_state_t *dds)

 dr = dbuf_dirty_record_create(dds);

+   /*
+* XXX - convert to ASSERT after dn_free_ranges fix
+*/
+   VERIFY(db->db_level == 0);
+   VERIFY(db->db_blkid != DMU_BONUS_BLKID);


Can't find context for both chunks, there are simply no such functions 
in sys/contrib/openzfs/module/zfs/dbuf.c, and yes, note that I'm running 
the in-tree version.

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

panic in range_tree_seg64_compare()

[Yuri Pankov]

Yet another issue I'm seeing after last update (currently running 
r364870), hit it 2 times today:


Fatal trap 12: page fault while in kernel mode
cpuid = 19; apic id = 0d
fault virtual address   = 0xf819e2ecdc40
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x8277fa64
stack pointer   = 0x28:0xfe01f9ff2d90
frame pointer   = 0x28:0xfe01f9ff2d90
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 48792 (blk-3:0-0)
trap number = 12
panic: page fault
cpuid = 19
time = 1598577675
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe01f9ff2a40

vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
panic() at panic+0x43/frame 0xfe01f9ff2af0
trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
--- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp = 
0xfe01f9ff2d90 ---
range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame 
0xfe01f9ff2d90

zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30
range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame 
0xfe01f9ff3030

dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame 
0xfe01f9ff3180

g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
physio() at physio+0x4f8/frame 0xfe01f9ff3270
devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
--- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp = 
0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---

Uptime: 4h13m43s

Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using 
for bhyve VM.  Anything known?

___
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: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR

[Yuri Pankov]

bob prohaska wrote:

On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote:

Another issue that I started seeing lately, didn't try finding out when
exactly in case someone knows what it's about:

Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed,
USB_ERR_IOERROR


[details snipped]


So far not seeing any ill effects from this, i.e. I can connect USB HDD to
these ports, and it's successfully detected.


If it's convenient, connecting a USB-serial adapter and rebooting might
be interesting. I'm having trouble with FT232 obstructing disk detection
in some cases and self-disconnecting in others on a Pi3B.


Don't have one.  It is "desktop" PC, so the only USB devices I have/need 
are keyboard/mouse and memsticks.

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

usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR

[Yuri Pankov]

Another issue that I started seeing lately, didn't try finding out when 
exactly in case someone knows what it's about:


Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed, 
USB_ERR_IOERROR

Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed, 
USB_ERR_IOERROR

Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed, 
USB_ERR_IOERROR

Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed, 
USB_ERR_IOERROR

Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 6 failed, 
USB_ERR_IOERROR

ugen0.7:  at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
Root mount waiting for: usbus0
ugen0.7:  at usbus0

ugen0.7:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=SAVE (0mA)


  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0310
  bDeviceClass = 0x0009  
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x0003
  bMaxPacketSize0 = 0x0009
  idVendor = 0x0bda
  idProduct = 0x0423
  bcdDevice = 0x0103
  iManufacturer = 0x0001  
  iProduct = 0x0002  <2-Port USB 3.1 Hub>
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001

So far not seeing any ill effects from this, i.e. I can connect USB HDD 
to these ports, and it's successfully detected.

___
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: can't handle raw ops yet!!!

[Yuri Pankov]

Matthew Macy wrote:

Expected. I'm working on it. It's just a friendly reminder when
INVARIANTS is enabled.


Good, thanks.


On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov  wrote:


After OpenZFS merge, during boot I'm getting several occurrences of what
seems to be the following:

http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207

And, yes, I'm running GENERIC, so with INVARIANTS.

Should I be worried?

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

can't handle raw ops yet!!!

[Yuri Pankov]

After OpenZFS merge, during boot I'm getting several occurrences of what 
seems to be the following:


http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207

And, yes, I'm running GENERIC, so with INVARIANTS.

Should I be worried?
___
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: FreeBSD Quarterly Status Report - Second Quarter 2020

[Yuri Pankov]

Daniel Ebdrup Jensen wrote:
[nothing]

At least in Thunderbird the text is not inline, and rather shows as 
attachment.

___
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: svn commit: r352558 - head/usr.bin/top

[Yuri Pankov]

Steve Wills wrote:

Hi,

On 7/10/20 7:12 PM, Yuri Pankov wrote:



Thanks.

The attached diff seems to take care of the issue for me, adding 
VIS_TAB and removing VIS_SAFE, which can be blamed for passing through 
the following:


VIS_SAFE   Currently this form allows space, tab, newline, backspace,
    bell, and return — in addition to all graphic characters —
    unencoded.


That does seem to fix it for me. Please commit. :)


Done, please report if it's still not completely fixed.
___
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: Current panics on connecting disks to a LSI-3108 controller

[Yuri Pankov]

Willem Jan Withagen wrote:

Hi,

I have this Supermicro SUPERSERVER®2028TP
Which hold four nodes each with a X10DRT-PT motherboard
and a LSI-3108 SAS controller connecting to 6 disks.

Trying to run the most recent current snapshot on it.
# uname -a
FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 
r363032: Thu Jul  9 04:13:17 UTC 2020 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64


I have installed the OS on a SATA flash DOM.
Booting works fine as long as there are no disks connected to LSI-3108 
controller.

Booting with SAS disks connected results in a panic.
Attaching a SAS disk to the LSI-3108 controller give a panic as well.



AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd
mfi0:  port 0x6000-0x60ff mem 
0xc730-0xc730,0xc720-0xc72f irq 26 at device

0.0 numa-domain 0 on pci3
mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfi0: FW MaxCmds = 928, limiting to 128
mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0
.
mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started 
(PCI ID 005d/1000/0809/15d9)
pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - 
Firmware version 4.290.00-4536



I have posted screenshots of the panic at:
     www.tegenbosch28.nl/FreeBSD/Crash-LSI3108

But basically it crashes in
     mfi_tbolt_send_frame() +0x132

So is there anybody out there that can help me with analyzing and fixing 
this panic?


I guess it's not the answer you are looking for, but you could try the 
mrsas driver and check if it's behaves better for you, by setting 'set 
hw.mfi.mrsas_enable=1' from loader prompt.

___
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: svn commit: r352558 - head/usr.bin/top

[Yuri Pankov]

Mark Millard wrote:



On 2020-Jul-10, at 16:12, Yuri Pankov  wrote:


Mark Millard wrote:

On 2020-Jul-10, at 11:05, Yuri Pankov  wrote:

Steve Wills wrote:

On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote:

Author: daichi
Date: Fri Sep 20 17:37:23 2019
New Revision: 352558
URL:
https://svnweb.freebsd.org/changeset/base/352558


Log:
top(1): support multibyte characters in command names (ARGV array)
depending on locale.
 - add setlocale()
 - remove printable() function
 - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
   non-printable characters that do not use C-style backslash sequences
   in three digit octal sequence, or remove it
This change allows multibyte characters to be displayed according to
locale. If it is recognized as a non-display character according to the
locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.


Apologies for the way late reply here, but I just now bothered tracking this down. This 
commit seems to be the cause of some corruption I'm seeing in long running top(1) as 
well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla 
bug? I can share screenshots of the corruption, such as:
https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png


Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() doesn't 
look wrong as vis(3) should take of its functionality (and in multibyte-aware 
way).

vis (as used) and the old isprintable logic are not
equivalent when multi-byte is not needed/involved.
Otherwise I'd not have had anything to ever report.
If vis can do what is needed, more work needed to
be done when the change was made in order to avoid
msesed up displays in single-byte contexts.

Also, is there an easy way to reproduce this?

The following sort of command (the empty space inside quoted
text are tab characters):
# tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0  
 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > 
/dev/null
causes my 200 character wide window running top to show:
32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   207172  
5448Ki CPU23   23   0:00   0.04% top -HiSCazopid
But that does not show where the lines wrap at the edges of the window,
so breaking it up explicitly after the first "\" in \\7:
32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\
\t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
-HiSCazopid
Note how \n turned into \\n , taking an extra character for
each \n . Similarly for \t vs. \\t . (Other examples do
similarly.)
The tab characters really do use more than one character cell
on the display (sometimes).
The text from the tr command ends up spread across 2 lines
as things look like in the window where top is running.
I ran top in another ssh session first and then the tr command.
Before running the tr command, top showed as:
33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
-HiSCazopid
If you do not end up with top listed just after tr in top's output,
then it will not be top's line that ends up partially overwritten.
If you have wider windows, you may need more text in the tr quoted
strings.
In another experiment I inserted a large number of backspace characters
(control-H's) at the front of the first quoted string in the tr command.
The top output displayed:
0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
\nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t
33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
-HiSCazopid
In other words, backspace moved the cursor position back over prior
fields on the line and then the later line content overwrote those
fields instead of being after "tr" someplace (or truncated off).
Note that part of "-HiSCazopid" shows up on both lines. The extra
is from when top was running but tr had not started yet. top is
not managing text replacement correctly for output characters that
end up not being just "in

Re: svn commit: r352558 - head/usr.bin/top

[Yuri Pankov]

Mark Millard wrote:



On 2020-Jul-10, at 11:05, Yuri Pankov  wrote:


Steve Wills wrote:

On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote:

Author: daichi
Date: Fri Sep 20 17:37:23 2019
New Revision: 352558
URL:
https://svnweb.freebsd.org/changeset/base/352558


Log:
top(1): support multibyte characters in command names (ARGV array)
depending on locale.
 - add setlocale()
 - remove printable() function
 - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
   non-printable characters that do not use C-style backslash sequences
   in three digit octal sequence, or remove it
This change allows multibyte characters to be displayed according to
locale. If it is recognized as a non-display character according to the
locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.


Apologies for the way late reply here, but I just now bothered tracking this down. This 
commit seems to be the cause of some corruption I'm seeing in long running top(1) as 
well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla 
bug? I can share screenshots of the corruption, such as:
https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png


Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() doesn't 
look wrong as vis(3) should take of its functionality (and in multibyte-aware 
way).


vis (as used) and the old isprintable logic are not
equivalent when multi-byte is not needed/involved.
Otherwise I'd not have had anything to ever report.
If vis can do what is needed, more work needed to
be done when the change was made in order to avoid
msesed up displays in single-byte contexts.


Also, is there an easy way to reproduce this?


The following sort of command (the empty space inside quoted
text are tab characters):

# tr '0\n  1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0  
 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > 
/dev/null

causes my 200 character wide window running top to show:

32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\\t733   \\t8   207172  
5448Ki CPU23   23   0:00   0.04% top -HiSCazopid

But that does not show where the lines wrap at the edges of the window,
so breaking it up explicitly after the first "\" in \\7:

32920 root1000  12764Ki2420Ki CPU3 3   2:22  99.87% tr 0\\n 
1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0   \\t1
\\t2\\t3\\t4\\t5\\t6\
\t733   \\t8   207172  5448Ki CPU23   23   0:00   0.04% top 
-HiSCazopid

Note how \n turned into \\n , taking an extra character for
each \n . Similarly for \t vs. \\t . (Other examples do
similarly.)

The tab characters really do use more than one character cell
on the display (sometimes).

The text from the tr command ends up spread across 2 lines
as things look like in the window where top is running.

I ran top in another ssh session first and then the tr command.
Before running the tr command, top showed as:

33019 root 200  17172Ki5448Ki CPU24   24   0:00   0.05% top 
-HiSCazopid

If you do not end up with top listed just after tr in top's output,
then it will not be top's line that ends up partially overwritten.

If you have wider windows, you may need more text in the tr quoted
strings.

In another experiment I inserted a large number of backspace characters
(control-H's) at the front of the first quoted string in the tr command.
The top output displayed:

0\\n5 ro1\\n2\\93   3\\n12764\\n   25\\ni CP6\\n   97\\n:12 100.00\t0r 
\nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t
33094 root 200  17172Ki5488Ki CPU21   21   0:00   0.06% top 
-HiSCazopid

In other words, backspace moved the cursor position back over prior
fields on the line and then the later line content overwrote those
fields instead of being after "tr" someplace (or truncated off).

Note that part of "-HiSCazopid" shows up on both lines. The extra
is from when top was running but tr had not started yet. top is
not managing text replacement correctly for output characters that
end up not being just "in" the next character-cell on the terminal.

The 

Re: DRM Project report (week of July 6th)

[Yuri Pankov]

Emmanuel Vadot wrote:
[...]

Hi Emmanuel,

Sorry for somewhat hijacking the thread, but as you mentioned (IIRC) 
testing the vmwgfx in one of the previous mails, I'd like to ask if any 
work/fixes is done for that.  Currently I don't have a VM with X11 
installed as all my attempts didn't succeed -- it's either a hard hang, 
panic, or VM dying with exception, even with a workaround of 1 CPU 
(core) provided in the Wiki.  I can reinstall and provide panic info if 
you are interested in looking into it.

___
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: svn commit: r352558 - head/usr.bin/top

[Yuri Pankov]

Steve Wills wrote:

On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote:

Author: daichi
Date: Fri Sep 20 17:37:23 2019
New Revision: 352558
URL:
https://svnweb.freebsd.org/changeset/base/352558


Log:
   top(1): support multibyte characters in command names (ARGV array)
   depending on locale.
    - add setlocale()
    - remove printable() function
    - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display
  non-printable characters that do not use C-style backslash 
sequences

  in three digit octal sequence, or remove it
   This change allows multibyte characters to be displayed according to
   locale. If it is recognized as a non-display character according 
to the

   locale, it is displayed in three digit octal sequence.



Initially picking on tab characters as an example of what is
probably a somewhat broader issue . . .

Ever since this change, characters like tabs that do not fit
in the next character cell when output, but for which they
are !isprintable(...), now mess up the top display. Again
using tab as an example: line wrapping from the text having
been shifted over by more than one character cell. top does
not track the line wrapping result in how it decides what
to output for the following display updates.



Apologies for the way late reply here, but I just now bothered tracking 
this down. This commit seems to be the cause of some corruption I'm 
seeing in long running top(1) as well. As Mark mentions, if I use "hh" 
it clears up. Should I open a bugzilla bug? I can share screenshots of 
the corruption, such as:


https://i.imgur.com/Xqlwf9h.png
https://i.imgur.com/Jv0d5NU.png


Does removing VIS_SAFE fixes the issue for you?

As for original Mark's report (which I missed), removing isprintable() 
doesn't look wrong as vis(3) should take of its functionality (and in 
multibyte-aware way).


Also, is there an easy way to reproduce this?
___
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: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)

[Yuri Pankov]

Mark Millard wrote:



On 2020-Jul-8, at 20:35, Yuri Pankov  wrote:


Mark Millard wrote:

This seems to have broken doing buildworld buildkernel and
other things using make:
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String 
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String 
comparison operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison 
operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison 
operator should be either == or !=
. . .
Using -d c shows the likes of:
. . .
lhs = "clang", rhs = "clang", op = ==
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op 
= ==
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String 
comparison operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
lhs = "LD", rhs = "LD", op = ==
. . .
left = 6.00, right = 2.00, op = <=
left = 6.00, right = 1.00, op = <=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "clang", 
op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison 
operator should be either == or !=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op 
= ==
lhs = "clang", rhs = "gcc", op = ==
. . .
left = 0.00, right = 6.00, op = <=
left = 0.00, right = 3.00, op = <=
lhs = "clang", rhs = "gcc", op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison 
operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
left = 11.00, right = 7.00, op = >=
lhs = "amd64", rhs = "arm", op = ==
(Now I just need to figure out how to get back to a working context.)


For me, buildworld/buildkernel produced only warnings,


But, looking at the code in bmake, the expression is also
evaluated differently/incorrectly when it is classified as
having the problem of having a incorrect operator. In other
words: the behavior in make changes via misevaluated
expressions.



though the one in ports is real issue:

$ make config
make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison 
operator should be either == or !=
make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional 
(defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} < ${_MAKE_JOBS_NUMBER} ))
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/devel/subversion


Not the only "real issue", I'm afraid.


Yeah, sorry, looks like I'm late to the party, and it was already 
discussed and reverted.

___
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: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)

[Yuri Pankov]

Mark Millard wrote:

This seems to have broken doing buildworld buildkernel and
other things using make:

make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String 
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String 
comparison operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison 
operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison 
operator should be either == or !=
. . .

Using -d c shows the likes of:

. . .
lhs = "clang", rhs = "clang", op = ==
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op 
= ==
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String 
comparison operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
lhs = "LD", rhs = "LD", op = ==
. . .
left = 6.00, right = 2.00, op = <=
left = 6.00, right = 1.00, op = <=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "clang", 
op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison 
operator should be either == or !=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op 
= ==
lhs = "clang", rhs = "gcc", op = ==
. . .
left = 0.00, right = 6.00, op = <=
left = 0.00, right = 3.00, op = <=
lhs = "clang", rhs = "gcc", op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison 
operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
left = 11.00, right = 7.00, op = >=
lhs = "amd64", rhs = "arm", op = ==

(Now I just need to figure out how to get back to a working context.)


For me, buildworld/buildkernel produced only warnings, though the one in 
ports is real issue:


$ make config
make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison 
operator should be either == or !=
make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional 
(defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} < 
${_MAKE_JOBS_NUMBER} ))

make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/devel/subversion
___
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: `shutdown -p now` fails to power off with VirtualBox UEFI boot

[Yuri Pankov]

Olivier Cochard-Labbé wrote:

On Thu, Jun 18, 2020 at 10:26 PM Yasuhiro KIMURA  wrote:


I have VirtualBox VM running 13-CURRENT. In order to switch from
legacy BIOS to UEFI I reinstalled OS by using
FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that
`shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power
off. Shutdown itself completes successfully. But power off never
happens and CPU usage keeps high until either closing or resetting VM.

I reinstalled OS by using
FreeBSD-13.0-CURRENT-amd64-20200618-r362292-disc1.iso but the problem
still happens. If I switch back to legacy BIOS then the problem
disappears. And it doesn't happen with either 11.4-RELEASE and
12.1-RELEASE.


Hi,


Same problem using FreeBSD current UEFI guests with bhyve, so it should
happen in any kind of hypervisor.
It is an old regression (in the sense of -current, so older than 6 months).
My idea was to generate very light UEFI VM images (because the snapshot VM
images are BIOS based) and scripting a bisector tool, but I never took the
time to do it.


FWIW, shutdown works for me in VMware Workstation (Windows) and ESXi 
VMs, UEFI boot.

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

uma_zalloc_debug warnings after r362231

[Yuri Pankov]

I've started getting the following after r362231 (I think) when plugging 
USB drive, not seeing any real issues though:


ugen0.9:  at usbus0 

umass0 numa-domain 0 on uhub4 

umass0: 10> on usbus0

umass0:  SCSI over Bulk-Only; quirks = 0xc101
umass0:2:0: Attached to scbus2
uma_zalloc_debug: zone "kenv" with the following non-sleepable locks held:
exclusive sleep mutex CAM device lock (CAM device lock) r = 0 
(0xf8000dcb6cd0) locked @ /usr/src/sys/cam/scsi/scsi_pass.c:674

stack backtrace:
#0 0x80c32981 at witness_debugger+0x71
#1 0x80c3391d at witness_warn+0x40d
#2 0x80efe426 at uma_zalloc_arg+0x46
#3 0x80b741da at getenv_string_buffer+0x3a
#4 0x80b74907 at getenv_quad+0x17
#5 0x80b748d2 at getenv_int+0x12
#6 0x803a7f1a at daregister+0x1ea
#7 0x8037445b at cam_periph_alloc+0x57b
#8 0x803a7872 at daasync+0x2c2
#9 0x80381aa2 at xpt_async_process_dev+0x152
#10 0x8037d682 at xpt_async_process+0x312
#11 0x8037ddf2 at xpt_done_process+0x382
#12 0x8037fdb5 at xpt_done_td+0xf5
#13 0x80b831e0 at fork_exit+0x80
#14 0x810413ce at fork_trampoline+0xe
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 575845314136394150553136
da0: 40.000MB/s transfers
da0: 953837MB (1953458176 512 byte sectors)
da0: quirks=0x2
___
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: lockups on lenovo p43s under current

[Yuri Pankov]

Pete Wright wrote:

hello,
i have a lenovo thinkpad P43s that exhibits lockups under CURRENT but 
behaves fine when running STABLE.  i've tried to find a fully 
reproducible situation to get this system to lockup but haven't found 
anything yet.  i am starting to suspect that the changes implemented in 
this review may be the issue though:


https://reviews.freebsd.org/D23728

my reasoning is that i've observed issues when:
- removing AC power from the laptop, or inserting AC power
- when the system display has gone to sleep
- randomly hanging during boot with this as last line:
battery0: battery enitialization start

unfortunately while the above seem to be cases where this has happened i 
haven't been able to %100 reproduce yet.


so my first question is - would it be possible to just revert the 
changes in that diff, or has too much time gone past to just back out 
that single change.  alternatively, is there any debugging information i 
can get on my end that might help figure out what the root cause is?


Not really what you are asking, but it's possible to disable ACPI 
subdevices, so you could check if disabling cmbat completely helps and 
it's indeed the suspect:


debug.acpi.disabled="cmbat"
___
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: nvme on 2019 macbooks

[Yuri Pankov]

Yuri Pankov wrote:
I have tried booting latest -current snapshot on 2019 macbook pro 16, 
and noticed that nvme driver didn't attach, as class reported is 
0x018002 and not 0x010802 that we expect in nvme_pci.c.


The following linux changes seem to be related:
https://github.com/torvalds/linux/commit/66341331ba0d2de4ff421cdc401a1e34de50502a 

https://github.com/torvalds/linux/commit/d38e9f04ebf667d9cb8185b45bff747485f1d3e9 



I have tried adding the exact PCI IDs, but that also fails as number of 
msix vectors seems to be 0 in nvme_ctrlr_setup_interrupts() and 
nvme_ctrlr_configure_intx() fails with "unable to allocate shared IRQ".


Any hints on how to proceed here?


So it looks like we need to fallback to MSI if we failed to enable 
MSI-X.  With the attached patch we still fail to attach the target 
device (as below) most likely due to the quirks needed as seen in linux 
driver, but it's definitely a start:


nvme0: CREATE IO CQ (05) sqid:0 cid:15 nsid:0 cdw10:0081 cdw11:00010003
nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme0: nvme_create_io_cq failed!
diff --git a/sys/dev/nvme/nvme_pci.c b/sys/dev/nvme/nvme_pci.c
index 448bfda6a718..e609967b53fe 100644
--- a/sys/dev/nvme/nvme_pci.c
+++ b/sys/dev/nvme/nvme_pci.c
@@ -90,6 +90,7 @@ static struct _pcsid
{ 0x05401c5f,   0, 0, "Memblaze Pblaze4", 
QUIRK_DELAY_B4_CHK_RDY },
{ 0xa821144d,   0, 0, "Samsung PM1725", QUIRK_DELAY_B4_CHK_RDY 
},
{ 0xa822144d,   0, 0, "Samsung PM1725a", QUIRK_DELAY_B4_CHK_RDY 
},
+   { 0x2005106b,   0, 0, "ANS2 NVMe Controller" },
{ 0x,   0, 0, NULL  }
 };
 
@@ -267,7 +268,7 @@ nvme_ctrlr_setup_interrupts(struct nvme_controller *ctrlr)
 
force_intx = 0;
TUNABLE_INT_FETCH("hw.nvme.force_intx", _intx);
-   if (force_intx || pci_msix_count(dev) < 2) {
+   if (force_intx) {
nvme_ctrlr_configure_intx(ctrlr);
return;
}
@@ -297,9 +298,14 @@ nvme_ctrlr_setup_interrupts(struct nvme_controller *ctrlr)
/* One vector for per core I/O queue, plus one vector for admin queue. 
*/
num_vectors_requested = num_io_queues + 1;
num_vectors_allocated = num_vectors_requested;
+
+   /* Try MSI-X */
if (pci_alloc_msix(dev, _vectors_allocated) != 0) {
-   nvme_ctrlr_configure_intx(ctrlr);
-   return;
+   /* MSI-X failed, try MSI */
+   if (pci_alloc_msi(dev, _vectors_allocated) != 0) {
+   nvme_ctrlr_configure_intx(ctrlr);
+   return;
+   }
}
if (num_vectors_allocated < 2) {
pci_release_msi(dev);
___
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"

nvme on 2019 macbooks

[Yuri Pankov]

I have tried booting latest -current snapshot on 2019 macbook pro 16, 
and noticed that nvme driver didn't attach, as class reported is 
0x018002 and not 0x010802 that we expect in nvme_pci.c.


The following linux changes seem to be related:
https://github.com/torvalds/linux/commit/66341331ba0d2de4ff421cdc401a1e34de50502a
https://github.com/torvalds/linux/commit/d38e9f04ebf667d9cb8185b45bff747485f1d3e9

I have tried adding the exact PCI IDs, but that also fails as number of 
msix vectors seems to be 0 in nvme_ctrlr_setup_interrupts() and 
nvme_ctrlr_configure_intx() fails with "unable to allocate shared IRQ".


Any hints on how to proceed here?

pciconf excerpt:
none7@pci0:4:0:0:	class=0x018002 rev=0x01 hdr=0x00 vendor=0x106b 
device=0x2005 subvendor=0x106b subdevice=0x1800

vendor  = "Apple Inc."
device  = "ANS2 NVMe Controller"
class   = mass storage
bar	[10]	= type Prefetchable Memory, range 64, base 0xc040, 
size 419304, enabled
bar	[18]	= type Prefetchable Memory, range 64, base 0xc140, 
size 524288, enabled
bar	[20]	= type Prefetchable Memory, range 64, base 0xc160, 
size 65536, enabled

cap 01[40]  = powerspec 3  supports D0 D3  current D0
cap 05[50]  = MSI supports 8 messages, 64 bit
cap 10[70]  = PCI-Express 2 endpoint max data 256(256) RO NS
  link x4(x4) speed 8.0(8.0) ASPM L1(L1) ClockPM enabled
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0019[148] = PCIe Sec 1 lane errors 0
ecap 0018[168] = LTR 1
ecap 001e[170] = L1 PM Substated 1
ecap 000b[180] = Vendor [1] ID 0002 Rev 1 Length 256
ecap 0015[280] = Resizable BAR 1
___
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: installkernel ignoring WITHOUT_DEBUG_FILES?

[Yuri Pankov]

Mark Johnston wrote:

On Wed, Apr 29, 2020 at 08:49:00AM +0300, Yuri Pankov wrote:

I'm trying to replace the kernel on memstick image with the help of
mdconfig, and installkernel runs out of space despite
WITHOUT_DEBUG_FILES= added to /etc/src.conf.

/usr/src$ make -V MK_DEBUG_FILES
no
/usr/src$ sudo rm -rf /mnt/usr/lib/debug
/usr/src$ sudo make DESTDIR=/mnt installkernel


You need WITHOUT_KERNEL_SYMBOLS= instead for the kernel.  I'm not sure
why it's a different option.


Thank you, somehow I missed it, and its description is a bit misleading 
as well.

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

installkernel ignoring WITHOUT_DEBUG_FILES?

[Yuri Pankov]

I'm trying to replace the kernel on memstick image with the help of 
mdconfig, and installkernel runs out of space despite 
WITHOUT_DEBUG_FILES= added to /etc/src.conf.


/usr/src$ make -V MK_DEBUG_FILES
no
/usr/src$ sudo rm -rf /mnt/usr/lib/debug
/usr/src$ sudo make DESTDIR=/mnt installkernel
--
>>> Install check kernel
--
--
>>> Installing kernel GENERIC on Wed Apr 29 08:43:19 MSK 2020
--
cd /usr/obj/usr/src/amd64.amd64/sys/GENERIC;  MACHINE_ARCH=amd64 
MACHINE=amd64  CPUTYPE= CC="cc -target x86_64-unknown-freebsd13.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++  -target 
x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target 
x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" LD="ld" 
LLVM_LINK=""  NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS= 
SIZE="size" 
PATH=/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin 
make  KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ;  if [ 
! "`dirname "$thiskernel"`" -ef /mnt/boot/kernel ] ; then  chflags
-R noschg /mnt/boot/kernel ;  rm -rf /mnt/boot/kernel ;  rm -rf 
/mnt/usr/lib/debug/boot/kernel ;  else  if [ -d /mnt/boot/kernel.old ] ; 
then  chflags -R noschg /mnt/boot/kernel.old ;  rm -rf 
/mnt/boot/kernel.old ;  fi ;  mv /mnt/boot/kernel /mnt/boot/kernel.old ; 
 if [ -n "/usr/lib/debug" -a  -d /mnt/usr/lib/debug/boot/kernel ]; then 
rm -rf /mnt/usr/lib/debug/boot/kernel.old ;  mv 
/mnt/usr/lib/debug/boot/kernel /mnt/usr/lib/debug/boot/kernel.old ;  fi 
;  sysctl kern.bootfile=/mnt/boot/kernel.old/"`basename "$thiskernel"`" 
;  fi

mkdir -p /mnt/boot/kernel
install -p -m 555 -o root -g wheel kernel /mnt/boot/kernel/
mkdir -p /mnt/usr/lib/debug/boot/kernel
install -p -m 555 -o root -g wheel kernel.debug 
/mnt/usr/lib/debug/boot/kernel/
cd /usr/src/sys/modules; 
MAKEOBJDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules 
KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 MACHINE=amd64 
MACHINE_ARCH=amd64 MODULES_EXTRA="" WITHOUT_MODULES="" ARCH_FLAGS="" 
DEBUG_FLAGS="-g" __MPATH="" DESTDIR="/mnt" 
KERNBUILDDIR="/usr/obj/usr/src/amd64.amd64/sys/GENERIC" 
SYSDIR="/usr/src/sys" MODULE_TIED=yes WITH_CTF="1" KCSAN_ENABLED="yes" 
make  install

===> aac (install)
install -T release -o root -g wheel -m 555   aac.ko /mnt/boot/kernel/
install -T debug -o root -g wheel -m 555   aac.ko.debug 
/mnt/usr/lib/debug/boot/kernel/

...
===> dummynet (install)
install -T release -o root -g wheel -m 555   dummynet.ko /mnt/boot/kernel/

/mnt: write failed, filesystem is full
install: /mnt/boot/kernel/dummynet.ko: No space left on device
___
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: Outdated jemalloc in CURRENT

[Yuri Pankov]

Gordon Bergling wrote:

I am not sure, that this info is correct. As far as I remember the update for 
jemalloc was reverted due to build problems, on some architecture. An updated 
revision has still to be commited to -CURRENT.


That's exactly what the commit log says, yes?


On Sat, Apr 18, 2020 at 07:20:03AM -0700, Steve Kargl wrote:

On Sat, Apr 18, 2020 at 03:05:25PM +0300, nonamel...@ukr.net wrote:

Hi everyone!

As I see, CURRENT still uses outdated jemalloc 5.1.0 with some performance 
regressions that was fixed in 5.2.1.

Are there some issues that blocking update jemalloc to recent version?




r354606 | jasone | 2019-11-10 21:06:49 -0800 (Sun, 10 Nov 2019) | 4 lines

Revert r354605: Update jemalloc to version 5.2.1.

Compilation fails for non-llvm-based platforms.


r354605 | jasone | 2019-11-10 19:27:14 -0800 (Sun, 10 Nov 2019) | 2 lines

Update jemalloc to version 5.2.1.

___
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: PCIe NVME drives not detected on Dell R6515

[Yuri Pankov]

Scott Long wrote:




On Apr 17, 2020, at 3:07 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

Scott Long wrote on 04/17/2020 23:04:

On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

Scott Long wrote on 04/17/2020 22:17:

On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

Kurt Jaeger wrote on 04/17/2020 21:44:

Hi!

pciconf -lBc pcib12
pciconf -lBc pcib13


Printscreen attached.

Attachments are stripped from the list -- can you put them somewhere
online ?


Here it is https://ibb.co/c1dZrTf

Miroslav Lachman


Ok, the bridges know about their downstream bus numbers, but I see nothing that 
suggests that they’re being probed.  The next step would be bootverbose, but 
that’s going to be a lot of output to collect in screen captures.


Over 3000 lines long but I finally managed to make SOL work so I have it as 
text!

https://pastebin.pl/view/90fdaafb


This helped a lot, thanks.  It looks like these PCIe buses are marked as being 
hotplug, and for some reason we’re not probing them.  At this point, I’d need 
to feed you some kernel patches that will dump out more info, but you’d have to 
compile them and get them onto your boot media.  Is that a possibility?


Currently I have all machines on 11.3 (where I can rebuild kernel without 
problem)
If CURRENT is required I would need to setup some CURRENT VM in VirtualBox.

Can you send me some link to documentation who should I create new ISO after 
rebuild?



I don’t know of any docs for doing custom releases, and it looks like it’s 
harder than it used to be to insert custom patches.  That said, I recommend 
doing the following on your 11.x build system:

1.  Do a clean `make buildworld` with an up-to-date tree
2.  change into the `release` directory that you just did the buildworld from
3.  `sudo make release NOPORTS= NODOC= CHROOTDIR=/usr/tmp/release 
SRCBRANCH="base/stable/11@rHEAD”`

You can set CHROOTDIR to whatever you want that has a few GB of space, but 
remember where you’ve set it for later steps.  This will build a release with 
stock sources.  Let it complete, both to prepare for the next step and to 
ensure that it works.  It’ll take an hour or two depending on your machine speed

4.  Take the patch that I’ll send you shortly and apply it to $CHROOTDIR/usr/src
5.  `sudo make memstick NOPORTS= NODOC= SRC_UPDATE_SKIP= 
CHROOTDIR=/usr/tmp/release`


Just a thought - it could possibly be easier to build just the patched 
kernel and try booting it (11.3 userland should work with CURRENT 
kernel, right?), doing the kernel-toolchaing target first, and using 
INSTKERNNAME with the installkernel target to temporary select it from 
loader menu.

___
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: buildkernel failure because ctfconvert not installed

[Yuri Pankov]

Trond Endrestøl wrote:

On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:


OK, I figured it out.

I used to have MK_CTF=no in src.conf, but I recently changed it to
WITH_CTF=no.


It's either WITH_xxx=yes or WITHOUT_xxx=yes.


Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that 
value is NOT checked:


The values of variables are ignored regardless of their setting; even if 
 they would be set to "FALSE" or "NO".  The presence of an option 
causes it to be honored by make(1).



/sys/conf/kern.post.mk checks whether MK_CTF is no and apparently
does not invoke ctfconvert if that is the case.

I put MK_CTF=no back into src.conf.

So, now everything works without having cftconvert installed.




___
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: CURRENT crashes if loader.conf contains «net.isr.dispatch="direct"»

[Yuri Pankov]

Lev Serebryakov wrote:

Hello FreeBSD-Current,

CURRENT (and64, r359632) crashes very early on boot if
`/boot/loader.conf` contains this line:

net.isr.dispatch="direct"

  Stacktrace (manually transcribed from photo of screen, as it is very early
stage of boot, so no crashdump possible):


calltrap()
--- trap 0xc
malloc()
sysctl_handle_string()
sysctl_netisr_dispatch_policy()
sysctl_root_handler_locked()
sysctl_register_oid()
sysctl_regioster_all()
mi_startup()
btext()

   It is 100% reproducable for me, with GENERIC kernel.

   Sorry, it is very hard to bisect across clang10 import commit :-(

But I suspect, it is very long-standing problem, at least 3 or 4 months.


It's likely r357614, reverting that commit helps.
___
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"