wlan0 functional for me with n249159-bb61ccd530b (was: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0)

[Graham Perrin]

On 05/09/2021 14:36, David Wolfskill wrote:

a reality check would almost certainly be helpful. :-)



No problem here; .

n248984-08b9cc316a3 (2021-08-28) upgraded to n249159-bb61ccd530b 
(2021-09-05),



Functional ☑ but (an old bug) wrongly connected to an open network when 
I manually bring up wlan0:




> 256957 – Wi-Fi: rc.conf(5) NOAUTO, ifconfig(8) up and unwanted WLAN 
connections to open networks




Below, ignore the dates of creation (most are false):

root@mowa219-gjp4-8570p-freebsd:~ # bectl list
BE    Active Mountpoint Space Created
default   -  -  789M  2021-08-26 16:33
n247565-b49ba74deeb-f -  -  36.7G 2021-08-26 19:50
n247798-f39dd6a9784-a -  -  22.9M 2021-08-26 22:54
n247798-f39dd6a9784-e -  -  328M  2021-08-26 22:55
n247798-f39dd6a9784-j -  -  4.98G 2021-08-26 22:55
n248139-3a57f08b504-b -  -  1.21G 2021-08-26 22:54
n248269-941650aae97-b -  -  524M  2021-08-26 22:54
n248269-941650aae97-d -  -  260M  2021-08-26 22:55
n248269-941650aae97-e -  -  40.5M 2021-08-26 22:54
n248269-941650aae97-f -  -  5.02G 2021-08-26 22:54
n248984-08b9cc316a3-d -  -  997M  2021-09-03 08:00
n249159-bb61ccd530b-a NR /  46.9G 2021-09-06 00:24
root@mowa219-gjp4-8570p-freebsd:~ #

-CURRENT compilation time

[Jeremie Le Hen]

Hey,

I want to build -CURRENT again from sources. It's been a long time
since I hadn't done that. I'm shocked by the compilation time.

I started the whole thing on Friday night and Monday morning it's
still in stage 4.2 (building libraries). Through occasional glancing
at the screen over the weekend, it seems obvious to me that the
compilation time is utterly dominated by LLVM.  Compiling C++ seems
extremely CPU heavy and this is made worse by the fact LLVM is built
twice (once for build/cross tools, once for the actual world).

So OK, my CPU is not the most powerful out there but it's still decent [1].

So I have a couple of questions coming to my mind:
1. Is there any optimization I could benefit from? (I'm sure there's a
knob to use the existing compiler instead of building a
cross-compiler.)
2. More generally, isn't this compilation time not considered as a
problem for developers? This seems to terribly slow down the iteration
time for people working on the build system. I wouldn't be surprised
if this drove people away from working on/improving that area.

[1] 
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz&id=2671

Cheers,
-- 
Jeremie Le Hen
j...@freebsd.org

Re: -CURRENT compilation time

[Michael Schuster]

Jeremie,

a few observations (from the POV of someone who builds current ~ once a
month)

On Mon, Sep 6, 2021 at 10:09 AM Jeremie Le Hen  wrote:

> Hey,
>
> I want to build -CURRENT again from sources. It's been a long time
> since I hadn't done that. I'm shocked by the compilation time.
>
> I started the whole thing on Friday night and Monday morning it's
> still in stage 4.2 (building libraries). Through occasional glancing
> at the screen over the weekend, it seems obvious to me that the
> compilation time is utterly dominated by LLVM.


Do you actually measure anything?
have you looked into what your I/O is doing? How about swap?

Compiling C++ seems
> extremely CPU heavy and this is made worse by the fact LLVM is built
> twice (once for build/cross tools, once for the actual world).
>
> So OK, my CPU is not the most powerful out there but it's still decent [1].
>

I didn't check the specs: how many cores does your box have, and how many
are you actually using (-j N)? IME, htop gives a good idea of how busy the
CPUs really are.

> So I have a couple of questions coming to my mind:
> 1. Is there any optimization I could benefit from? (I'm sure there's a
> knob to use the existing compiler instead of building a
> cross-compiler.)
>

look at the build man page (https://www.freebsd.org/cgi/man.cgi?build(7))
for some tips on how to configure your environment.

2. More generally, isn't this compilation time not considered as a
> problem for developers? This seems to terribly slow down the iteration
> time for people working on the build system. I wouldn't be surprised
> if this drove people away from working on/improving that area.
>
> [1]
> https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz&id=2671
>
> Cheers,
> --
> Jeremie Le Hen
> j...@freebsd.org
>
>
regards
Michael
-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: -CURRENT compilation time

[Guido Falsi via freebsd-current]

On 06/09/21 10:08, Jeremie Le Hen wrote:

Hey,

I want to build -CURRENT again from sources. It's been a long time
since I hadn't done that. I'm shocked by the compilation time.

I started the whole thing on Friday night and Monday morning it's
still in stage 4.2 (building libraries). Through occasional glancing
at the screen over the weekend, it seems obvious to me that the
compilation time is utterly dominated by LLVM.  Compiling C++ seems
extremely CPU heavy and this is made worse by the fact LLVM is built
twice (once for build/cross tools, once for the actual world).

So OK, my CPU is not the most powerful out there but it's still decent [1].

So I have a couple of questions coming to my mind:
1. Is there any optimization I could benefit from? (I'm sure there's a
knob to use the existing compiler instead of building a
cross-compiler.)


I'm routinely compiling head once a month or so on an "i7-6700 CPU @ 
3.40GHz" (from dmesg), slightly more powerful than an i5 but this is a 
relatively old one so not top notch anymore. It usually takes less than 
4 hours. I also build a NanoBSD image from scratch from time to time to 
an even older i5, which takes a little longer, but always under 6 hours, 
so the build times you report look anomalous.


So as already suggested make sure yiu are using parallel make jobs (-j 
option to make) and memory is large enough (I think you need at least 2 
GiB for make job is the minimum to not risk thrashing.


You should really enable meta mode (look for WITH_META_MODE in 
src.conf(5)). It will not help the first time but will help a lot in 
future recompilations with an already populated /usr/obj.


You could also investigate using ccache, which again will only help for 
successive rebuilds, and will consume a fair amount of disk space.


Another consideration, my builds are happening on SSD disks, with swap 
on SSD, if you have everything on spinning media that is also a slowing 
factor. If you have plenty of ram you could build in ram, which is what 
I'm doing with poudriere for ports and it really speeds things up (even 
SSD disks tend to get slower when hit with a constant high load of mixed 
read/write accesses, which poudriere with parallel builds sometime causes)


Hope this helps!

--
Guido Falsi 

Re: -CURRENT compilation time

[David Chisnall]

On 06/09/2021 09:08, Jeremie Le Hen wrote:

Compiling C++ seems
extremely CPU heavy and this is made worse by the fact LLVM is built
twice (once for build/cross tools, once for the actual world).


Note that you need to build LLVM twice only if you are actively 
debugging LLVM reproduceable deployment images.  You actually don't need 
to build it at all, you can use an external toolchain to skip the first 
build and you can compile WITHOUT_TOOLCHAIN  to avoid building the 
version that's installed and then install a toolchain from packages:


https://wiki.freebsd.org/ExternalToolchain

David

Re: -CURRENT compilation time

[Jeffrey Bouquet]

On Mon, 6 Sep 2021 10:43:06 +0100, David Chisnall  wrote:

> On 06/09/2021 09:08, Jeremie Le Hen wrote:
> > Compiling C++ seems
> > extremely CPU heavy and this is made worse by the fact LLVM is built
> > twice (once for build/cross tools, once for the actual world).
> 
> Note that you need to build LLVM twice only if you are actively 
> debugging LLVM reproduceable deployment images.  You actually don't need 
> to build it at all, you can use an external toolchain to skip the first 
> build and you can compile WITHOUT_TOOLCHAIN  to avoid building the 
> version that's installed and then install a toolchain from packages:
> 
> https://wiki.freebsd.org/ExternalToolchain
> 
> David


If only that suggestion was topmost in UPDATING and repeated in each
security advisory... 

Re: -CURRENT compilation time

[Wolfram Schneider]

On Mon, 6 Sept 2021 at 10:10, Jeremie Le Hen  wrote:
>
> Hey,
>
> I want to build -CURRENT again from sources. It's been a long time
> since I hadn't done that. I'm shocked by the compilation time.
>
> I started the whole thing on Friday night and Monday morning it's
> still in stage 4.2 (building libraries). Through occasional glancing
> at the screen over the weekend, it seems obvious to me that the
> compilation time is utterly dominated by LLVM.  Compiling C++ seems
> extremely CPU heavy and this is made worse by the fact LLVM is built
> twice (once for build/cross tools, once for the actual world).
>
> So OK, my CPU is not the most powerful out there but it's still decent [1].
>
> So I have a couple of questions coming to my mind:
> 1. Is there any optimization I could benefit from? (I'm sure there's a
> knob to use the existing compiler instead of building a
> cross-compiler.)
> 2. More generally, isn't this compilation time not considered as a
> problem for developers? This seems to terribly slow down the iteration
> time for people working on the build system. I wouldn't be surprised
> if this drove people away from working on/improving that area.
>
> [1] 
> https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz&id=2671

Hi,

I ran buildworld yesterday on a 3 CPU VM (AMD EPYC 2.4GHz) and the
runtime was 2h. We spent most of the time in "stage 4.2: building
libraries", in my case 62% of the CPU time and 75% of the real time.

I guess the build time on your laptop should be around 6 hours if
everything is ok.


time make -j $(sysctl -n hw.ncpu) buildworld  > log.buildworld 2>&1

tail -n 5 log.buildworld
--
>>> World build completed on Sat Sep  4 20:58:00 UTC 2021
>>> World built in 7235 seconds, ncpu: 3, make -j3
--
 7235.61 real 20527.30 user   915.88 sys

egrep '>>> stage| real ' log.buildworld
>>> stage 1.1: legacy release compatibility shims
0.28 real 0.18 user 0.10 sys
>>> stage 1.2: bootstrap tools
  165.99 real   472.58 user11.56 sys
>>> stage 2.1: cleaning up the object tree
   21.47 real36.96 user14.14 sys
   15.87 real29.14 user11.87 sys
>>> stage 2.3: build tools
2.42 real 3.79 user 0.62 sys
>>> stage 3: cross tools
9.92 real18.49 user 1.75 sys
>>> stage 3.1: recording build metadata
0.07 real 0.01 user 0.06 sys
>>> stage 4.1: building includes
   16.62 real36.46 user 9.48 sys
>>> stage 4.2: building libraries
 5440.89 real 15724.60 user   482.58 sys
>>> stage 4.3: building lib32 shim libraries
  615.91 real  1654.77 user   164.58 sys
>>> stage 4.4: building everything
  937.23 real  2540.06 user   205.47 sys

-Wolfram

-- 
Wolfram Schneider  https://wolfram.schneider.org

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Idwer Vollering]

Op ma 6 sep. 2021 om 07:53 schreef Cy Schubert :
>
> In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> writes:
> > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > then), but after updating the "head" slice of my laptopp from:
> > >
> > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > amd64 1400032 1400032
> > >
> > > to:
> > >
> > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > amd64 1400032 1400032
> > >
> > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
> > > the WLAN LED doesn't light up.
> >
> >  I am also experiencing issues with wlan after my current update to
> > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > demonstrating the same behavior  - wlan can not associate.
> > You can mitigate it by using security/wpa_supplicant from ports as 
> > replacemen
> > t
> > of wpa_supplicant in base.
> >
> > .
> > >
> > > I note that exactly the same hardware works OK in stable/12 and stable/13.
> > >
> > > Peace,
> > > david
> >
>
> Can you grep wpa_supplicant in /var/log/messages? This will give us a clue.

wpa_supplicant stops in wpa_driver_bsd_scan() -
https://github.com/freebsd/freebsd-src/blob/bd452dcbede69b1862c769f244948f94b86448b5/contrib/wpa/src/drivers/driver_bsd.c#L1315

Here's some selected output from /var/log/messages.

Before (built from commit a0c64a443e4cae67a5eea3a61a47d746866de3ee):

Sep  6 13:29:40  wpa_supplicant[45348]: Successfully
initialized wpa_supplicant
Sep  6 13:29:40  wpa_supplicant[45348]: ioctl[SIOCS80211,
op=20, val=0, arg_len=7]: Invalid argument
Sep  6 13:29:40  syslogd: last message repeated 1 times
Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Trying to
associate with  (SSID='' freq=2447 MHz)
Sep  6 13:29:46  wpa_supplicant[45349]: Failed to add
supported operating classes IE
Sep  6 13:29:46  kernel: wlan1: link state changed to UP
Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Associated with 
Sep  6 13:29:46  dhclient[45401]: send_packet: No buffer
space available
Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: WPA: Key
negotiation completed with  [PTK=CCMP GTK=CCMP]
Sep  6 13:29:46  wpa_supplicant[45349]: wlan1:
CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]

After (built from main):

Sep  6 12:19:50  wpa_supplicant[1236]: Successfully
initialized wpa_supplicant
Sep  6 12:19:50  kernel: wlan1: Ethernet address: 
Sep  6 12:19:50  wpa_supplicant[1236]: ioctl[SIOCS80211,
op=20, val=0, arg_len=7]: Invalid argument
Sep  6 12:19:50  syslogd: last message repeated 1 times
Sep  6 12:19:50  wpa_supplicant[1237]: wlan1:
CTRL-EVENT-SCAN-FAILED ret=-1 retry=1

>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
>
> The need of the many outweighs the greed of the few.
>
>
> >
> >
>
>
>

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Cy Schubert]

In message 
, Idwer Vollering writes:
> Op ma 6 sep. 2021 om 07:53 schreef Cy Schubert :
> >
> > In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> > writes:
> > > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > > then), but after updating the "head" slice of my laptopp from:
> > > >
> > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > > amd64 1400032 1400032
> > > >
> > > > to:
> > > >
> > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > > amd64 1400032 1400032
> > > >
> > > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
> > > > the WLAN LED doesn't light up.
> > >
> > >  I am also experiencing issues with wlan after my current update to
> > > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > > demonstrating the same behavior  - wlan can not associate.
> > > You can mitigate it by using security/wpa_supplicant from ports as replac
> emen
> > > t
> > > of wpa_supplicant in base.
> > >
> > > .
> > > >
> > > > I note that exactly the same hardware works OK in stable/12 and stable/
> 13.
> > > >
> > > > Peace,
> > > > david
> > >
> >
> > Can you grep wpa_supplicant in /var/log/messages? This will give us a clue.
>
> wpa_supplicant stops in wpa_driver_bsd_scan() -
> https://github.com/freebsd/freebsd-src/blob/bd452dcbede69b1862c769f244948f94b
> 86448b5/contrib/wpa/src/drivers/driver_bsd.c#L1315
>
> Here's some selected output from /var/log/messages.
>
> Before (built from commit a0c64a443e4cae67a5eea3a61a47d746866de3ee):
>
> Sep  6 13:29:40  wpa_supplicant[45348]: Successfully
> initialized wpa_supplicant
> Sep  6 13:29:40  wpa_supplicant[45348]: ioctl[SIOCS80211,
> op=20, val=0, arg_len=7]: Invalid argument
> Sep  6 13:29:40  syslogd: last message repeated 1 times
> Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Trying to
> associate with  (SSID='' freq=2447 MHz)
> Sep  6 13:29:46  wpa_supplicant[45349]: Failed to add
> supported operating classes IE
> Sep  6 13:29:46  kernel: wlan1: link state changed to UP
> Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Associated with  >
> Sep  6 13:29:46  dhclient[45401]: send_packet: No buffer
> space available
> Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: WPA: Key
> negotiation completed with  [PTK=CCMP GTK=CCMP]
> Sep  6 13:29:46  wpa_supplicant[45349]: wlan1:
> CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]
>
> After (built from main):
>
> Sep  6 12:19:50  wpa_supplicant[1236]: Successfully
> initialized wpa_supplicant
> Sep  6 12:19:50  kernel: wlan1: Ethernet address: 
> Sep  6 12:19:50  wpa_supplicant[1236]: ioctl[SIOCS80211,
> op=20, val=0, arg_len=7]: Invalid argument
> Sep  6 12:19:50  syslogd: last message repeated 1 times
> Sep  6 12:19:50  wpa_supplicant[1237]: wlan1:
> CTRL-EVENT-SCAN-FAILED ret=-1 retry=1

Is there a wpa_supplicant.core dump in / ?

Can you also send me a sanitized copy of wpa_supplicant.conf, please? I'm 
interested in the lines proto=, key_mgmt=, pairwise=, group=, eap=, and 
phase2=. You may not be using eap= or phase2=, which is fine. I'd like to 
see if there are any differences from what was tested. Though, looking at 
your outputs above you're probably using something like:

proto=RSN WPA
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP

Is this correct?

If you try ports/securitiy/wpa_supplicant-devel (same codebase as in 
14-CURRENT), does it work? (ports/security/wpa_supplicant is the old 2.9 
codebase.)

What is your AP set for? 802.11g, 802.11n, 802.11ac?


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Idwer Vollering]

There's no core dump in /, wpa_supplicant connects to 802.11b/g/n
(there's no way to lock this, instead of having a mix of standards) on
2,4GHz.

/etc/wpa_supplicant.conf:
network={
ssid="some ssid"
scan_ssid=1
key_mgmt=WPA-PSK
psk="some key"
}

Op ma 6 sep. 2021 om 15:23 schreef Cy Schubert :
>
> In message  om>
> , Idwer Vollering writes:
> > Op ma 6 sep. 2021 om 07:53 schreef Cy Schubert :
> > >
> > > In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> > > writes:
> > > > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > > > then), but after updating the "head" slice of my laptopp from:
> > > > >
> > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > > > amd64 1400032 1400032
> > > > >
> > > > > to:
> > > > >
> > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > > > amd64 1400032 1400032
> > > > >
> > > > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
> > > > > the WLAN LED doesn't light up.
> > > >
> > > >  I am also experiencing issues with wlan after my current update to
> > > > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > > > demonstrating the same behavior  - wlan can not associate.
> > > > You can mitigate it by using security/wpa_supplicant from ports as 
> > > > replac
> > emen
> > > > t
> > > > of wpa_supplicant in base.
> > > >
> > > > .
> > > > >
> > > > > I note that exactly the same hardware works OK in stable/12 and 
> > > > > stable/
> > 13.
> > > > >
> > > > > Peace,
> > > > > david
> > > >
> > >
> > > Can you grep wpa_supplicant in /var/log/messages? This will give us a 
> > > clue.
> >
> > wpa_supplicant stops in wpa_driver_bsd_scan() -
> > https://github.com/freebsd/freebsd-src/blob/bd452dcbede69b1862c769f244948f94b
> > 86448b5/contrib/wpa/src/drivers/driver_bsd.c#L1315
> >
> > Here's some selected output from /var/log/messages.
> >
> > Before (built from commit a0c64a443e4cae67a5eea3a61a47d746866de3ee):
> >
> > Sep  6 13:29:40  wpa_supplicant[45348]: Successfully
> > initialized wpa_supplicant
> > Sep  6 13:29:40  wpa_supplicant[45348]: ioctl[SIOCS80211,
> > op=20, val=0, arg_len=7]: Invalid argument
> > Sep  6 13:29:40  syslogd: last message repeated 1 times
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Trying to
> > associate with  (SSID='' freq=2447 MHz)
> > Sep  6 13:29:46  wpa_supplicant[45349]: Failed to add
> > supported operating classes IE
> > Sep  6 13:29:46  kernel: wlan1: link state changed to UP
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Associated with 
> >  > >
> > Sep  6 13:29:46  dhclient[45401]: send_packet: No buffer
> > space available
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: WPA: Key
> > negotiation completed with  [PTK=CCMP GTK=CCMP]
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1:
> > CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]
> >
> > After (built from main):
> >
> > Sep  6 12:19:50  wpa_supplicant[1236]: Successfully
> > initialized wpa_supplicant
> > Sep  6 12:19:50  kernel: wlan1: Ethernet address: 
> > Sep  6 12:19:50  wpa_supplicant[1236]: ioctl[SIOCS80211,
> > op=20, val=0, arg_len=7]: Invalid argument
> > Sep  6 12:19:50  syslogd: last message repeated 1 times
> > Sep  6 12:19:50  wpa_supplicant[1237]: wlan1:
> > CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
>
> Is there a wpa_supplicant.core dump in / ?
>
> Can you also send me a sanitized copy of wpa_supplicant.conf, please? I'm
> interested in the lines proto=, key_mgmt=, pairwise=, group=, eap=, and
> phase2=. You may not be using eap= or phase2=, which is fine. I'd like to
> see if there are any differences from what was tested. Though, looking at
> your outputs above you're probably using something like:
>
> proto=RSN WPA
> key_mgmt=WPA-PSK
> pairwise=CCMP
> group=CCMP
>
> Is this correct?
>
> If you try ports/securitiy/wpa_supplicant-devel (same codebase as in
> 14-CURRENT), does it work? (ports/security/wpa_supplicant is the old 2.9
> codebase.)
>
> What is your AP set for? 802.11g, 802.11n, 802.11ac?
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
>
> The need of the many outweighs the greed of the few.
>
>

BUG in libm's powf

[Steve Kargl]

Paul Zimmermann has identified a bug in Openlibm's powf(),
which is identical to FreeBSD's libm.  Both derived from
fdlibm. https://github.com/JuliaMath/openlibm/issues/212.

Consider

% cat h.c
#include 
#include 
int
main(void)
{
   float x, y, z;
   x =  0x1.ecp-1F;
   y = -0x1.02p+27F;
   z =  0x1.557a86p115F;
   printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
   return 0;
}

% cc -o h -fno-builtin h.c -lm && ./h
9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34

Note, clang seems to have a builtin for powf(), but one cannot
count of clang being the only consumer of libm.  With the patch
at the end of this email, I get

% cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34

Watch for copy and paste whitespace corruption.

--- /usr/src/lib/msun/src/e_powf.c  2021-02-21 03:29:00.956878000 -0800
+++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
@@ -136,7 +136,7 @@
 /* |y| is huge */
if(iy>0x4d00) { /* if |y| > 2**27 */
/* over/underflow if x is not close to one */
-   if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
+   if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
/* now |1-x| is tiny <= 2**-20, suffice to compute
   log(x) by x-x^2/2+x^3/3-x^4/4 */


-- 
Steve

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Cy Schubert]

I changed mine to be the same as yours. I can connect. (I use iwn(4) and 
ath(4) here.)

Do you reboot every time you test or simply this?

service netif stop wlan0
service netif start wlan0

If simply above, does a reboot have it work again?

The reason I ask is, I discovered, today, a quirk in 14-CURRENT, regardless 
of the wpa_supplicant installed. It will always associate following a 
reboot however when running the above two commands to stop and start wlan0 
I can reproduce your problem. The workaround for now is when running the 
above two commands to also ifconfig wlan0 down; ifconfig wlan0 up.

Can you try ifconfig wlan0 down; ifconfig wlan0 up after stopping/starting 
wlan0? You may need to wait 2-3 seconds between down and up.

If this occurs at boot, try the ifconfig down and up anyway (to help narrow 
down the problem).



-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.



In message 
, Idwer Vollering writes:
> There's no core dump in /, wpa_supplicant connects to 802.11b/g/n
> (there's no way to lock this, instead of having a mix of standards) on
> 2,4GHz.
>
> /etc/wpa_supplicant.conf:
> network={
> ssid="some ssid"
> scan_ssid=1
> key_mgmt=WPA-PSK
> psk="some key"
> }
>
> Op ma 6 sep. 2021 om 15:23 schreef Cy Schubert :
> >
> > In message  c
> > om>
> > , Idwer Vollering writes:
> > > Op ma 6 sep. 2021 om 07:53 schreef Cy Schubert  >:
> > > >
> > > > In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> > > > writes:
> > > > > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > > > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > > > > then), but after updating the "head" slice of my laptopp from:
> > > > > >
> > > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > > > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > > > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CA
> NARY
> > > > > > amd64 1400032 1400032
> > > > > >
> > > > > > to:
> > > > > >
> > > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > > > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > > > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CA
> NARY
> > > > > > amd64 1400032 1400032
> > > > > >
> > > > > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does n
> ot:
> > > > > > the WLAN LED doesn't light up.
> > > > >
> > > > >  I am also experiencing issues with wlan after my current update to
> > > > > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > > > > demonstrating the same behavior  - wlan can not associate.
> > > > > You can mitigate it by using security/wpa_supplicant from ports as re
> plac
> > > emen
> > > > > t
> > > > > of wpa_supplicant in base.
> > > > >
> > > > > .
> > > > > >
> > > > > > I note that exactly the same hardware works OK in stable/12 and sta
> ble/
> > > 13.
> > > > > >
> > > > > > Peace,
> > > > > > david
> > > > >
> > > >
> > > > Can you grep wpa_supplicant in /var/log/messages? This will give us a c
> lue.
> > >
> > > wpa_supplicant stops in wpa_driver_bsd_scan() -
> > > https://github.com/freebsd/freebsd-src/blob/bd452dcbede69b1862c769f244948
> f94b
> > > 86448b5/contrib/wpa/src/drivers/driver_bsd.c#L1315
> > >
> > > Here's some selected output from /var/log/messages.
> > >
> > > Before (built from commit a0c64a443e4cae67a5eea3a61a47d746866de3ee):
> > >
> > > Sep  6 13:29:40  wpa_supplicant[45348]: Successfully
> > > initialized wpa_supplicant
> > > Sep  6 13:29:40  wpa_supplicant[45348]: ioctl[SIOCS80211,
> > > op=20, val=0, arg_len=7]: Invalid argument
> > > Sep  6 13:29:40  syslogd: last message repeated 1 times
> > > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Trying to
> > > associate with  (SSID='' freq=2447 MHz)
> > > Sep  6 13:29:46  wpa_supplicant[45349]: Failed to add
> > > supported operating classes IE
> > > Sep  6 13:29:46  kernel: wlan1: link state changed to UP
> > > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Associated with 
>  > > >
> > > Sep  6 13:29:46  dhclient[45401]: send_packet: No buffer
> > > space available
> > > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: WPA: Key
> > > negotiation completed with  [PTK=CCMP GTK=CCMP]
> > > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1:
> > > CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]
> > >
> > > After (built from main):
> > >
> > > Sep  6 12:19:50  wpa_supplicant[1236]: Successfully
> > > initialized wpa_supplicant
> > > Sep  6 12:19:50  kernel: wlan1: Ethernet address: 
> > > Sep  6 12:19:50  wpa_supplicant[1236]: ioctl[SIOCS80211,
> > > op=20, val=0, arg_len=7]: Invalid argument
> > > Sep  6 12:19:50  syslogd: last message repeated 1 times
> > > Sep  6 12:19:50  wpa_supplicant[1237]: wlan1:
> > > CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
> 

Install to ZFS root is using device names hence failing when device tree is changed.

[Karel Gardas]

Hello,

just installed 14-current snapshot from 2.9. on uefi amd64 machine. 
Installed from USB memstick which was detected as da0 into the ssd 
hanging on usb3 in external enclosure which was detected as da1.


ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as 
/boot/efi and probably also something as root zpool.


Anyway, expected thing happen. When I pulled out USB stick identified as 
da0 on reboot, the drive on USB3 switch from da1 to da0 and result is 
unbootable system with complains about various /dev/da1xx drives missing 
for swap efi boot etc.


Would be great if ZFS root install was using kind of device uuids or 
serial numbers or so so such device change would not disrupt freebsd 
from running correctly.


Thanks,
Karel

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 16:23:21 EEST Cy Schubert wrote:
> In message  om>
> 
> , Idwer Vollering writes:
> > Op ma 6 sep. 2021 om 07:53 schreef Cy Schubert 
:
> > > In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> > > 
> > > writes:
> > > > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > > > then), but after updating the "head" slice of my laptopp from:
> > > > > 
> > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CAN
> > > > > ARY
> > > > > amd64 1400032 1400032
> > > > > 
> > > > > to:
> > > > > 
> > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CAN
> > > > > ARY
> > > > > amd64 1400032 1400032
> > > > > 
> > > > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does
> > > > > not:
> > > > > the WLAN LED doesn't light up.
> > > >  
> > > >  I am also experiencing issues with wlan after my current update to
> > > > 
> > > > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > > > demonstrating the same behavior  - wlan can not associate.
> > > > You can mitigate it by using security/wpa_supplicant from ports as
> > > > replac
> > 
> > emen
> > 
> > > > t
> > > > of wpa_supplicant in base.
> > > > 
> > > > .
> > > > 
> > > > > I note that exactly the same hardware works OK in stable/12 and
> > > > > stable/
> > 
> > 13.
> > 
> > > > > Peace,
> > > > > david
> > > 
> > > Can you grep wpa_supplicant in /var/log/messages? This will give us a
> > > clue.
> > 
> > wpa_supplicant stops in wpa_driver_bsd_scan() -
> > https://github.com/freebsd/freebsd-src/blob/bd452dcbede69b1862c769f244948f
> > 94b 86448b5/contrib/wpa/src/drivers/driver_bsd.c#L1315
> > 
> > Here's some selected output from /var/log/messages.
> > 
> > Before (built from commit a0c64a443e4cae67a5eea3a61a47d746866de3ee):
> > 
> > Sep  6 13:29:40  wpa_supplicant[45348]: Successfully
> > initialized wpa_supplicant
> > Sep  6 13:29:40  wpa_supplicant[45348]: ioctl[SIOCS80211,
> > op=20, val=0, arg_len=7]: Invalid argument
> > Sep  6 13:29:40  syslogd: last message repeated 1 times
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Trying to
> > associate with  (SSID='' freq=2447 MHz)
> > Sep  6 13:29:46  wpa_supplicant[45349]: Failed to add
> > supported operating classes IE
> > Sep  6 13:29:46  kernel: wlan1: link state changed to UP
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Associated with
> >  > 
> > Sep  6 13:29:46  dhclient[45401]: send_packet: No buffer
> > space available
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: WPA: Key
> > negotiation completed with  [PTK=CCMP GTK=CCMP]
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1:
> > CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]
> > 
> > After (built from main):
> > 
> > Sep  6 12:19:50  wpa_supplicant[1236]: Successfully
> > initialized wpa_supplicant
> > Sep  6 12:19:50  kernel: wlan1: Ethernet address: 
> > Sep  6 12:19:50  wpa_supplicant[1236]: ioctl[SIOCS80211,
> > op=20, val=0, arg_len=7]: Invalid argument
> > Sep  6 12:19:50  syslogd: last message repeated 1 times
> > Sep  6 12:19:50  wpa_supplicant[1237]: wlan1:
> > CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
> 
> Is there a wpa_supplicant.core dump in / ?

 No

> 
> Can you also send me a sanitized copy of wpa_supplicant.conf, please? I'm
> interested in the lines proto=, key_mgmt=, pairwise=, group=, eap=, and
> phase2=. You may not be using eap= or phase2=, which is fine.

# grep -E -2 "proto=|key_mgmt=|pairwise=|group=|eap=|phase2=" /etc/
wpa_supplicant.conf
network={
priority=0
key_mgmt=NONE
}

Config of active wireless network looks like 

network={
ssid=",,,"
scan_ssid=0
psk="..."
priority=4
}


Global section of /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
ap_scan=1
fast_reauth=1




> I'd like to
> see if there are any differences from what was tested. Though, looking at
> your outputs above you're probably using something like:
> 
> proto=RSN WPA
> key_mgmt=WPA-PSK
> pairwise=CCMP
> group=CCMP
> 
> Is this correct?
> 
> If you try ports/securitiy/wpa_supplicant-devel (same codebase as in
> 14-CURRENT), does it work? 
 
 No it fals to associate with same symptoms as wpa_supplicant from base.

> (ports/security/wpa_supplicant is the old 2.9
> codebase.)
> 
> What is your AP set for? 802.11g, 802.11n, 802.11ac?

 802.11gn

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 08:50:21 EEST Cy Schubert wrote:
> In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> 
> writes:
> > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > then), but after updating the "head" slice of my laptopp from:
> > > 
> > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > amd64 1400032 1400032
> > > 
> > > to:
> > > 
> > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > amd64 1400032 1400032
> > > 
> > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
> > > the WLAN LED doesn't light up.
> >  
> >  I am also experiencing issues with wlan after my current update to
> > 
> > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > demonstrating the same behavior  - wlan can not associate.
> > You can mitigate it by using security/wpa_supplicant from ports as
> > replacemen t
> > of wpa_supplicant in base.
> > 
> > .
> > 
> > > I note that exactly the same hardware works OK in stable/12 and
> > > stable/13.
> > > 
> > > Peace,
> > > david
> 
> Can you grep wpa_supplicant in /var/log/messages? This will give us a clue.

/var/log/messages:Sep  6 15:21:55 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:21:56 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:21:57 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:22:44 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:11 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:32 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:34 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:50 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1

Compare it to successful association attempt while I was using wpa_supplicant 
from ports:

/var/log/messages:Sep  6 15:19:21 asus wpa_supplicant[326]: wlan0: 
Authentication with MAC timed out.
/var/log/messages:Sep  6 15:19:21 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
DISCONNECTED bssid=MAC reason=3 locally_generated=1
/var/log/messages:Sep  6 15:19:21 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=1 duration=10 
reason=CONN_FAILED
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
SSID-REENABLED id=0 ssid="..."
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: Trying to 
associate with MAC (SSID='...' freq=2447 MHz)
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: Failed to add 
supported operating classes IE
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: Associated 
with MAC
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: WPA: Key 
negotiation completed with MAC [PTK=CCMP GTK=CCMP]
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
CONNECTED - Connection to MAC completed [id=0 id_str=]

wlan related settings from /etc/rc.conf

wlans_ath0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"


Thank you

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 18:41:13 EEST Cy Schubert wrote:
> I changed mine to be the same as yours. I can connect. (I use iwn(4) and
> ath(4) here.)

 a ) regular reboot - wlan can not associate
 b ) service netif restart - wlan can not associate
 c ) service netif stop wlan0 ; service netif start wlan0 - wlan can not 
associate
 d ) ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up - wlan associated
 e ) regular reboot with ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up 
added to /etc/rc.local - wlan associated

Thank you.

> 
> Do you reboot every time you test or simply this?
> 
>   service netif stop wlan0
>   service netif start wlan0
> 
> If simply above, does a reboot have it work again?
> 
> The reason I ask is, I discovered, today, a quirk in 14-CURRENT, regardless
> of the wpa_supplicant installed. It will always associate following a
> reboot however when running the above two commands to stop and start wlan0
> I can reproduce your problem. The workaround for now is when running the
> above two commands to also ifconfig wlan0 down; ifconfig wlan0 up.
> 
> Can you try ifconfig wlan0 down; ifconfig wlan0 up after stopping/starting
> wlan0? You may need to wait 2-3 seconds between down and up.

EFI/loader show garbage in console when set to some resolution in loader.conf

[Karel Gardas]

Hello,

I'm attempting to set EFI console resolution in loader to 1920x1920. 
This is working fine on all 3 tested* combinations when interrupting 
loader with '3' key and then

issueing 'gop set 11' command and then 'boot' command.

However I'd like to make that permanent and here issue comes. I've tried 
both:


- edit /boot/loader.conf by adding
 'exec="gop set 11"'

- edit /boot/loader.conf by adding
 'efi_max_resolution="1920x1920"'

neither of those works on neither of 3 tested combinations where tested 
combinations are:


(1) 13.0 release
(2) 13.0-p4 (stable)
(3) 14.0 snapshot from 2.9.

The behavior is still the same. Screen blanks (like it would do gop set 
11), then switches to text mode to show loader UI and when kernel
is loaded it correctly shows that efi resolution is 1920x1920 but then 
when kernels boot, it produce just garbage to the console like loader 
and kernel resolution would be off

by some unknown number...

Is this is known issue, is there a known workaround for it? Or shall I 
report it properly to bugzilla?


Thanks!
Karel

Re: EFI/loader show garbage in console when set to some resolution in loader.conf

[Toomas Soome via freebsd-current]

> On 6. Sep 2021, at 19:44, Karel Gardas  wrote:
> 
> Hello,
> 
> I'm attempting to set EFI console resolution in loader to 1920x1920. This is 
> working fine on all 3 tested* combinations when interrupting loader with '3' 
> key and then
> issueing 'gop set 11' command and then 'boot' command.
> 
> However I'd like to make that permanent and here issue comes. I've tried both:
> 
> - edit /boot/loader.conf by adding
>  'exec="gop set 11"'
> 
> - edit /boot/loader.conf by adding
>  'efi_max_resolution="1920x1920"'
> 
> neither of those works on neither of 3 tested combinations where tested 
> combinations are:

if you have this setting, what does gop get report? With the versions listed 
below, was the loader in ESP updated too?

> 
> (1) 13.0 release
> (2) 13.0-p4 (stable)
> (3) 14.0 snapshot from 2.9.
> 
> The behavior is still the same. Screen blanks (like it would do gop set 11), 
> then switches to text mode to show loader UI and when kernel
> is loaded it correctly shows that efi resolution is 1920x1920 but then when 
> kernels boot, it produce just garbage to the console like loader and kernel 
> resolution would be off
> by some unknown number...
> 
> Is this is known issue, is there a known workaround for it? Or shall I report 
> it properly to bugzilla?
> 
> Thanks!
> Karel
> 

what you get from: dmesg | grep efifb

rgds,
toomas

Re: PAM module for loading ZFS keys on login

[Eric McCorkle]

Honestly, I think the best approach to this is the autounmountd unload
keys thing.  There's just too many ways the sessions thing can go wrong.
 The autounmountd solution gets the job done, and it tolerates possible
failures better than anything else I can think of, barring some kind of
major kernel-side awareness of sessions.  There's potentially a gap
between the user logging out and the keys being unloaded, but that's not
much of a problem when you consider the most likely use case.

The thing to keep in mind with the primary use case I've suggested for
the ZFS key load/unload stuff is that it's not so much about preventing
the Adversary from gaining access to data is it is about constraining
when they need to be active to pull off an exfiltration.  This is the
real reason you see it on secure systems: it makes the Adversary's job a
lot harder, while at the same time making the jobs of defensive ops and
DFIR folks a whole lot easier.

Say I've got sensitive files in my home directory.  On a base system,
the Adversary just has to circumvent OS file protections, but they can
do this at any time.  This means your DFIR folks have to dig through a
huge amount of history.  If I have to be logged in for the keys to be
present, then the Adversary has to have some kind of monitoring to
detect when I am, and then has a constrained window in which to pull off
the attack.  Both of these increase the likelihood of detection, while
also constraining the window of time the DFIR folks have to examine.

This isn't changed much by having the system wait some small time
interval after I'm logged out to unmount my home directory and unload my
keys.  (If anything, it introduces another potential vector for
detection: the unmounting/unloading will fail if someone is still
accessing my data after I'm gone.)



On 9/6/21 10:01 AM, Steffen Nurpmeso wrote:
> Eric McCorkle wrote in
>  :
>  |Interesting, I wasn't aware of the upstream module.  I'd say that's
> 
> It's existence was the reason i have readded (now optional, and
> a tad different) session support for my pam_xdg PAM module,
> because i was thinking that, if such a many-eyes-seen thing of
> a software project that claims to be and aims at being enterprise,
> ships such a terrible and terribly broken thing, then i can also
> offer session tracking.  But my manual at least states
> 
>   CAVEATS
>On Unix systems any “daemonized” program or script is reparented to the
>program running with PID 1, most likely leaving the PAM user session
>without PAM recognizing this.  Yet careless such code may hold or 
> expect
>availability of resources of the session it just left, truly performing
>cleanup when sessions end seems thus unwise.  Since so many PAM modules
>do support session tracking and cleanup pam_xdg.so readded optional 
> sup‐
>port for this.
> 
> But the real solution would be PAM session tracking in-kernel,
> somehow, wouldn't it?
> Also, on FreeBSD and OpenPAM many separate files exist in
> /etc/pam.d for things which might open a session, whereas linuxpam
> at least has /etc/pam.d/common-session; it has many common- things
> in fact, and in /etc/pam.d/sshd i for example see
> 
>   #
>   # /etc/pam.d/sshd - openssh service module configuration
>   #
> 
>   authinclude common-auth
> 
>   account include common-account
> 
>   passwordinclude common-password
> 
>   session include common-session
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> 

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Cy Schubert]

One last favour to ask, can you try this with the wpa_supplicant-devel 
port, please? I'm trying to narrow down if this is related to the options 
in usr.sbin/wpa/Makefile.inc or an upstream problem. If this behaves the 
same using wpa_supplicant-devel, this tells me to look at the code instead 
of Makefiles.

I can reproduce the service netif restart problem using the old 
wpa_supplicant 2.9, so at least here there is no change in behaviour. 
Though on my sandbox machine the ifconfig dow/up is not required -- though 
even the older wpa_supplicant 2.9 behaves the same on my laptop, (no 
regression experienced here).

To help point to either Makefile.inc or contrib/wpa, can you please try the 
wpa_supplicant-devel port. This will tell me where to look next.

Fifteen seconds isn't needed. Two or three, even no wait, will do.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.


In message <3000346.zmr5pbt...@sigill.theweb.org.ua>, "Oleg V. Nauman" 
writes:
> On 2021 M09 6, Mon 18:41:13 EEST Cy Schubert wrote:
> > I changed mine to be the same as yours. I can connect. (I use iwn(4) and
> > ath(4) here.)
>
>  a ) regular reboot - wlan can not associate
>  b ) service netif restart - wlan can not associate
>  c ) service netif stop wlan0 ; service netif start wlan0 - wlan can not 
> associate
>  d ) ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up - wlan associated
>  e ) regular reboot with ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up 
> added to /etc/rc.local - wlan associated
>
> Thank you.
>
> > 
> > Do you reboot every time you test or simply this?
> > 
> > service netif stop wlan0
> > service netif start wlan0
> > 
> > If simply above, does a reboot have it work again?
> > 
> > The reason I ask is, I discovered, today, a quirk in 14-CURRENT, regardless
> > of the wpa_supplicant installed. It will always associate following a
> > reboot however when running the above two commands to stop and start wlan0
> > I can reproduce your problem. The workaround for now is when running the
> > above two commands to also ifconfig wlan0 down; ifconfig wlan0 up.
> > 
> > Can you try ifconfig wlan0 down; ifconfig wlan0 up after stopping/starting
> > wlan0? You may need to wait 2-3 seconds between down and up.
>
>

Re: BUG in libm's powf

[Mark Murray]

Hi

I've opened a Phab ticket for this. I hope that's OK?

https://reviews.freebsd.org/D31865

M

> On 6 Sep 2021, at 16:28, Steve Kargl  
> wrote:
> 
> Paul Zimmermann has identified a bug in Openlibm's powf(),
> which is identical to FreeBSD's libm.  Both derived from
> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> 
> Consider
> 
> % cat h.c
> #include 
> #include 
> int
> main(void)
> {
>   float x, y, z;
>   x =  0x1.ecp-1F;
>   y = -0x1.02p+27F;
>   z =  0x1.557a86p115F;
>   printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>   return 0;
> }
> 
> % cc -o h -fno-builtin h.c -lm && ./h
> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> 
> Note, clang seems to have a builtin for powf(), but one cannot
> count of clang being the only consumer of libm.  With the patch
> at the end of this email, I get
> 
> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> 
> Watch for copy and paste whitespace corruption.
> 
> --- /usr/src/lib/msun/src/e_powf.c2021-02-21 03:29:00.956878000 -0800
> +++ src/e_powf.c  2021-09-06 08:17:09.88000 -0700
> @@ -136,7 +136,7 @@
> /* |y| is huge */
>   if(iy>0x4d00) { /* if |y| > 2**27 */
>   /* over/underflow if x is not close to one */
> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>   if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>   /* now |1-x| is tiny <= 2**-20, suffice to compute
>  log(x) by x-x^2/2+x^3/3-x^4/4 */
> 
> 
> --
> Steve
> 

--
Mark R V Murray



signature.asc
Description: Message signed with OpenPGP

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 20:31:33 EEST Cy Schubert wrote:
> One last favour to ask, can you try this with the wpa_supplicant-devel
> port, please? I'm trying to narrow down if this is related to the options
> in usr.sbin/wpa/Makefile.inc or an upstream problem. If this behaves the
> same using wpa_supplicant-devel, this tells me to look at the code instead
> of Makefiles.
> 
> I can reproduce the service netif restart problem using the old
> wpa_supplicant 2.9, so at least here there is no change in behaviour.
> Though on my sandbox machine the ifconfig dow/up is not required -- though
> even the older wpa_supplicant 2.9 behaves the same on my laptop, (no
> regression experienced here).
> 
> To help point to either Makefile.inc or contrib/wpa, can you please try the
> wpa_supplicant-devel port. This will tell me where to look next.

 I can confirm that wpa_supplicant from security/wpa_supplicant-devel port 
demonstrating the same behavior as wpa_supplicant from base - "ifconfig wlan0 
down ; sleep 5 ; ifconfig wlan0 up" mitigate wlan association issue.

> 
> Fifteen seconds isn't needed. Two or three, even no wait, will do.

 Thank you

Re: BUG in libm's powf

[Steve Kargl]

Fine with me.  I don't have a phabricator account and
bugzilla reports seems to get lost in the ether.

-- 
steve

On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> Hi
> 
> I've opened a Phab ticket for this. I hope that's OK?
> 
> https://reviews.freebsd.org/D31865
> 
> M
> 
> > On 6 Sep 2021, at 16:28, Steve Kargl  
> > wrote:
> > 
> > Paul Zimmermann has identified a bug in Openlibm's powf(),
> > which is identical to FreeBSD's libm.  Both derived from
> > fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> > 
> > Consider
> > 
> > % cat h.c
> > #include 
> > #include 
> > int
> > main(void)
> > {
> >   float x, y, z;
> >   x =  0x1.ecp-1F;
> >   y = -0x1.02p+27F;
> >   z =  0x1.557a86p115F;
> >   printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> >   return 0;
> > }
> > 
> > % cc -o h -fno-builtin h.c -lm && ./h
> > 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> > 
> > Note, clang seems to have a builtin for powf(), but one cannot
> > count of clang being the only consumer of libm.  With the patch
> > at the end of this email, I get
> > 
> > % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
> > 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> > 
> > Watch for copy and paste whitespace corruption.
> > 
> > --- /usr/src/lib/msun/src/e_powf.c  2021-02-21 03:29:00.956878000 -0800
> > +++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
> > @@ -136,7 +136,7 @@
> > /* |y| is huge */
> > if(iy>0x4d00) { /* if |y| > 2**27 */
> > /* over/underflow if x is not close to one */
> > -   if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> > +   if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> > if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> > /* now |1-x| is tiny <= 2**-20, suffice to compute
> >log(x) by x-x^2/2+x^3/3-x^4/4 */
> > 
> > 
> > --
> > Steve
> > 
> 
> --
> Mark R V Murray
> 



-- 
Steve

Re: BUG in libm's powf

[Mark Murray]

Thanks!

And it's committed!

M

> On 6 Sep 2021, at 18:53, Steve Kargl  
> wrote:
> 
> Fine with me.  I don't have a phabricator account and
> bugzilla reports seems to get lost in the ether.
> 
> --
> steve
> 
> On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
>> Hi
>> 
>> I've opened a Phab ticket for this. I hope that's OK?
>> 
>> https://reviews.freebsd.org/D31865
>> 
>> M
>> 
>>> On 6 Sep 2021, at 16:28, Steve Kargl  
>>> wrote:
>>> 
>>> Paul Zimmermann has identified a bug in Openlibm's powf(),
>>> which is identical to FreeBSD's libm.  Both derived from
>>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
>>> 
>>> Consider
>>> 
>>> % cat h.c
>>> #include 
>>> #include 
>>> int
>>> main(void)
>>> {
>>>  float x, y, z;
>>>  x =  0x1.ecp-1F;
>>>  y = -0x1.02p+27F;
>>>  z =  0x1.557a86p115F;
>>>  printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
>>>  return 0;
>>> }
>>> 
>>> % cc -o h -fno-builtin h.c -lm && ./h
>>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
>>> 
>>> Note, clang seems to have a builtin for powf(), but one cannot
>>> count of clang being the only consumer of libm.  With the patch
>>> at the end of this email, I get
>>> 
>>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
>>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
>>> 
>>> Watch for copy and paste whitespace corruption.
>>> 
>>> --- /usr/src/lib/msun/src/e_powf.c  2021-02-21 03:29:00.956878000 -0800
>>> +++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
>>> @@ -136,7 +136,7 @@
>>>/* |y| is huge */
>>> if(iy>0x4d00) { /* if |y| > 2**27 */
>>> /* over/underflow if x is not close to one */
>>> -   if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>> +   if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
>>> if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
>>> /* now |1-x| is tiny <= 2**-20, suffice to compute
>>>log(x) by x-x^2/2+x^3/3-x^4/4 */
>>> 
>>> 
>>> --
>>> Steve
>>> 
>> 
>> --
>> Mark R V Murray
>> 
> 
> 
> 
> --
> Steve
> 

--
Mark R V Murray



signature.asc
Description: Message signed with OpenPGP

Install to ZFS root is using device names hence failing when device tree is changed.

[Karel Gardas]

Hello,

just installed 14-current snapshot from 2.9. on uefi amd64 machine. 
Installed from USB memstick which was detected as da0 into the ssd 
hanging on usb3 in external enclosure which was detected as da1.


ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as 
/boot/efi and probably also something as root zpool.


Anyway, expected thing happen. When I pulled out USB stick identified as 
da0 on reboot, the drive on USB3 switch from da1 to da0 and result is 
unbootable system with complains about various /dev/da1xx drives missing 
for swap efi boot etc.


Would be great if ZFS root install was using kind of device uuids or 
serial numbers or so so such device change would not disrupt freebsd 
from running correctly.


Thanks,
Karel

Re: BUG in libm's powf

[Steve Kargl]

No, thank you for the quick response.

Of course, a one character diff might be easier to review. :-)

-- 
steve 

On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote:
> Thanks!
> 
> And it's committed!
> 
> M
> 
> > On 6 Sep 2021, at 18:53, Steve Kargl  
> > wrote:
> > 
> > Fine with me.  I don't have a phabricator account and
> > bugzilla reports seems to get lost in the ether.
> > 
> > --
> > steve
> > 
> > On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> >> Hi
> >> 
> >> I've opened a Phab ticket for this. I hope that's OK?
> >> 
> >> https://reviews.freebsd.org/D31865
> >> 
> >> M
> >> 
> >>> On 6 Sep 2021, at 16:28, Steve Kargl  
> >>> wrote:
> >>> 
> >>> Paul Zimmermann has identified a bug in Openlibm's powf(),
> >>> which is identical to FreeBSD's libm.  Both derived from
> >>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> >>> 
> >>> Consider
> >>> 
> >>> % cat h.c
> >>> #include 
> >>> #include 
> >>> int
> >>> main(void)
> >>> {
> >>>  float x, y, z;
> >>>  x =  0x1.ecp-1F;
> >>>  y = -0x1.02p+27F;
> >>>  z =  0x1.557a86p115F;
> >>>  printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> >>>  return 0;
> >>> }
> >>> 
> >>> % cc -o h -fno-builtin h.c -lm && ./h
> >>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> >>> 
> >>> Note, clang seems to have a builtin for powf(), but one cannot
> >>> count of clang being the only consumer of libm.  With the patch
> >>> at the end of this email, I get
> >>> 
> >>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && 
> >>> ./h
> >>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> >>> 
> >>> Watch for copy and paste whitespace corruption.
> >>> 
> >>> --- /usr/src/lib/msun/src/e_powf.c2021-02-21 03:29:00.956878000 
> >>> -0800
> >>> +++ src/e_powf.c  2021-09-06 08:17:09.88000 -0700
> >>> @@ -136,7 +136,7 @@
> >>>/* |y| is huge */
> >>>   if(iy>0x4d00) { /* if |y| > 2**27 */
> >>>   /* over/underflow if x is not close to one */
> >>> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> >>> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> >>>   if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> >>>   /* now |1-x| is tiny <= 2**-20, suffice to compute
> >>>  log(x) by x-x^2/2+x^3/3-x^4/4 */
> >>> 
> >>> 
> >>> --
> >>> Steve
> >>> 
> >> 
> >> --
> >> Mark R V Murray
> >> 
> > 
> > 
> > 
> > --
> > Steve
> > 
> 
> --
> Mark R V Murray
> 



-- 
Steve

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Cy Schubert]

In message <2780735.ssxfcku...@sigill.theweb.org.ua>, "Oleg V. Nauman" 
writes:
> On 2021 M09 6, Mon 20:31:33 EEST Cy Schubert wrote:
> > One last favour to ask, can you try this with the wpa_supplicant-devel
> > port, please? I'm trying to narrow down if this is related to the options
> > in usr.sbin/wpa/Makefile.inc or an upstream problem. If this behaves the
> > same using wpa_supplicant-devel, this tells me to look at the code instead
> > of Makefiles.
> > 
> > I can reproduce the service netif restart problem using the old
> > wpa_supplicant 2.9, so at least here there is no change in behaviour.
> > Though on my sandbox machine the ifconfig dow/up is not required -- though
> > even the older wpa_supplicant 2.9 behaves the same on my laptop, (no
> > regression experienced here).
> > 
> > To help point to either Makefile.inc or contrib/wpa, can you please try the
> > wpa_supplicant-devel port. This will tell me where to look next.
>
>  I can confirm that wpa_supplicant from security/wpa_supplicant-devel port 
> demonstrating the same behavior as wpa_supplicant from base - "ifconfig wlan0
>  
> down ; sleep 5 ; ifconfig wlan0 up" mitigate wlan association issue.

Thank you.

This is an issue that I'll need to chase down with our upstream. In the 
mean time while work on this/bring it to upstream's attention this should 
circumvent the issue:

diff --git a/libexec/rc/rc.d/wpa_supplicant b/libexec/rc/rc.d/wpa_supplicant
index 8a86fec90e4d..cfe5f1ab27c6 100755
--- a/libexec/rc/rc.d/wpa_supplicant
+++ b/libexec/rc/rc.d/wpa_supplicant
@@ -12,6 +12,7 @@
 
 name="wpa_supplicant"
 desc="WPA/802.11i Supplicant for wireless network devices"
+start_postcmd="wpa_poststart"
 rcvar=
 
 ifn="$2"
@@ -27,6 +28,12 @@ is_ndis_interface()
esac
 }
 
+wpa_poststart() {
+   ifconfig ${ifn} down
+   sleep 3
+   ifconfig ${ifn} up
+}
+
 if is_wired_interface ${ifn} ; then
driver="wired"
 elif is_ndis_interface ${ifn} ; then

I'll have more questions later (need to start working on another job) but 
I'd like to learn more about your configuration to understand why it works 
at boot for myself and phlip@ and not for you and the others here on 
-current who have experienced the same issue. Understanding what triggers 
this will go a long way to resolving it.

(cc'd philip@)

BTW, my laptop is configured so that wlan0 (iwn0) and bge0 are members of 
lagg0. Whereas on my sandbox wlan0 (ath0) is used directly.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.

Re: EFI/loader show garbage in console when set to some resolution in loader.conf

[Karel Gardas]

On 9/6/21 6:59 PM, Toomas Soome wrote:



On 6. Sep 2021, at 19:44, Karel Gardas > wrote:


Hello,

I'm attempting to set EFI console resolution in loader to 1920x1920. 
This is working fine on all 3 tested* combinations when interrupting 
loader with '3' key and then

issueing 'gop set 11' command and then 'boot' command.

However I'd like to make that permanent and here issue comes. I've 
tried both:


- edit /boot/loader.conf by adding
 'exec="gop set 11"'

- edit /boot/loader.conf by adding
 'efi_max_resolution="1920x1920"'

neither of those works on neither of 3 tested combinations where 
tested combinations are:


if you have this setting, what does gop get report? With the versions 
listed below, was the loader in ESP updated too?


Good question. I'm not entirely sure if my 13.x installation is not 
update from 12.x. It probably is. IIRC I followed the update procedure 
recommended, but certainly 13.0 -> 13.0-p4 is just `fetch` and `install` 
matter. If you like me to update ESP bootloader,

I'm happy to follow your instructions how to do that.

Anyway, my 14.0-CURRENT is fresh install to separate drive in an attempt 
to duplicate issue also on current to report it here.


So gop get reports this (manually rewritten by hand):

- FreeBSD 14.0 - current:

EDID 1920x1920 1920x1920 1920x1200 1920x1080 1600x1200 1600x900 
1280x1024 1280x960 1280x720

mode 4: 1024x768x32, stride=1024
  frame buffer: address=d000, size=30
  color mark: R=00ff, G=ff00, B=00ff

- FreeBSD 13.0-p4:

EDID 1920x1920 1920x1920 1920x1200 1920x1080 1600x1200 1600x900 
1280x1024 1280x960 1280x720

mode 4: 1024x768x32, stride 1024
  frame buffer: address=d000, size 30
  color mark: R00ff, G=ff00, B00ff




(1) 13.0 release
(2) 13.0-p4 (stable)
(3) 14.0 snapshot from 2.9.

The behavior is still the same. Screen blanks (like it would do gop 
set 11), then switches to text mode to show loader UI and when kernel
is loaded it correctly shows that efi resolution is 1920x1920 but 
then when kernels boot, it produce just garbage to the console like 
loader and kernel resolution would be off

by some unknown number...

Is this is known issue, is there a known workaround for it? Or shall 
I report it properly to bugzilla?


Thanks!
Karel



what you get from: dmesg | grep efifb



- FreebSD 14.0-current:

VT(efifb): resolution 1920x1920

- FreeBSD 13.0-p4:

VT(efifb): resolution 1920x1920

Thanks,
Karel

Re: -CURRENT compilation time

[Wolfram Schneider]

On Mon, 6 Sept 2021 at 11:44, David Chisnall  wrote:
>
> On 06/09/2021 09:08, Jeremie Le Hen wrote:
> > Compiling C++ seems
> > extremely CPU heavy and this is made worse by the fact LLVM is built
> > twice (once for build/cross tools, once for the actual world).
>
> Note that you need to build LLVM twice only if you are actively
> debugging LLVM reproduceable deployment images.  You actually don't need
> to build it at all, you can use an external toolchain to skip the first
> build and you can compile WITHOUT_TOOLCHAIN  to avoid building the
> version that's installed and then install a toolchain from packages:
>
> https://wiki.freebsd.org/ExternalToolchain

I did a test on a 16 core (32 VCPU) machine (Intel(R) Xeon(R) CPU
E5-2630 v3 @ 2.40GHz).

With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5
times faster (real or user+sys), down from 48 min to 19.5 min real
time.

time make -j16 buildworld
--
>>> World build completed on Mon Sep  6 12:00:45 UTC 2021
>>> World built in 2862 seconds, ncpu: 32, make -j16
--
 2862.04 real 41234.87 user  1582.66 sys

time make -j16 WITHOUT_TOOLCHAIN=yes buildworld
--
>>> World build completed on Mon Sep  6 11:32:41 UTC 2021
>>> World built in 1181 seconds, ncpu: 32, make -j16
--
 1180.73 real 16076.27 user   988.73 sys

-Wolfram

-- 
Wolfram Schneider  https://wolfram.schneider.org

Re: BUG in libm's powf

[Steve Kargl]

On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote:
> could you turn to test program into an AFT test to prevent further 
> regressions?
> 
> —Gordon
> 

I cannot tell if you are addressing Mark or me.
For me, I know nothing about ATF.  I do, however,
suspect that this won't regress as I'm one of the
few people who actually looks at threshold issues
in libm.

-- 
Steve

Re: BUG in libm's powf

[Kurt Jaeger]

Hi!

> On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote:
> > could you turn to test program into an AFT test to prevent further 
> > regressions?
> 
> I cannot tell if you are addressing Mark or me.
> For me, I know nothing about ATF.

man 7 atf

has more details.

-- 
p...@opsec.eu+49 171 3101372Now what ?

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Filipe da Silva Santos via current]

> I'll have more questions later (need to start working on another job) but 
> I'd like to learn more about your configuration to understand why it works 
> at boot for myself and phlip@ and not for you and the others here on 
> -current who have experienced the same issue. Understanding what triggers 
> this will go a long way to resolving it.

Hello, Cy,
I have a Intel AC 3168 and can reproduce both problem and solution.

I'd love to help with testing and info with the new version.

Cheers!

--
Filipe da Silva Santos 
102E 1944 2189 31FF 06EB  3F79 760B AE45 F7B3 008E


signature.asc
Description: PGP signature

Re: PAM module for loading ZFS keys on login

[Eric McCorkle]

I looked at the upstream one too.

Mine is simple because I modified libzfs to be able to take the key
directly in the key location override argument.

If you look at my patch, it adds a "direct" key location, which
basically works like "direct:keydata", where "keydata" is your key.

In the case of the PAM module, this ends up being "direct:password".

It looks like they essentially pull in all the libzfs logic for
preparing keys.  If you notice, they go directly to lzc_load_key (that
is basically a thin wrapper around the ioctl).

It's worth noting that apparently they change the key to the dataset
when the user changes their password.

Anyway, I've seen enough.  I'm going to abandon the review for my PAM
module and use the upstream one.  I'm going to keep the review for the
autounmountd patch live, though.

On 9/6/21 2:53 PM, Steffen Nurpmeso wrote:
> Eric McCorkle wrote in
>  :
>  ...
>   >> This patch creates a new PAM module that will load a ZFS key upon a
>   >> successful login: https://reviews.freebsd.org/D31844.  It will use the
>   >> user's auth token as the key argument to loading a ZFS encryption key on
>   >> a user-specific ZFS data set.
>   ...
> 
> Without knowing about libzfs i personally was stunned about the
> simplicity of your patch, having read the upstream one.
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> 

Re: BUG in libm's powf

[Steve Kargl]

On Mon, Sep 06, 2021 at 10:40:21PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote:
> > > could you turn to test program into an AFT test to prevent further 
> > > regressions?
> > 
> > I cannot tell if you are addressing Mark or me.
> > For me, I know nothing about ATF.
> 
> man 7 atf
> 
> has more details.
> 

% man 7 atf
No manual entry for atf
% grep -i tests /etc/src.conf
WITHOUT_GOOGLETEST="YES"
WITHOUT_TESTS="YES"

-- 
Steve

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Cy Schubert]

In message <86tuix4cys@shiori.com.br>, Filipe da Silva Santos writes:
> --=-=-=
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> > I'll have more questions later (need to start working on another job) but=
> =20
> > I'd like to learn more about your configuration to understand why it work=
> s=20
> > at boot for myself and phlip@ and not for you and the others here on=20
> > -current who have experienced the same issue. Understanding what triggers=
> =20
> > this will go a long way to resolving it.
>
> Hello, Cy,
> I have a Intel AC 3168 and can reproduce both problem and solution.
>
> I'd love to help with testing and info with the new version.

Can you also try the security/wpa_supplicant and security/wpa_supplicant-dev
el ports, both without the ifconfig mitigation patch? This will more than 
confirm that this is an upstream problem and not in the FreeBSD Makefiles. 
This would be of great help as I cannot reproduce the problem at boot but 
after boot using service netif (which the old wpa_supplicant 2.9 also had).

An additional confirmation that the -devel port has the same problem would 
help a lot.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

The need of the many outweighs the greed of the few.

Re: BUG in libm's powf

[Kurt Jaeger]

Hi!

> > > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote:
> > > > could you turn to test program into an AFT test to prevent further 
> > > > regressions?
> > > 
> > > I cannot tell if you are addressing Mark or me.
> > > For me, I know nothing about ATF.
> > 
> > man 7 atf
> > 
> > has more details.

> % man 7 atf
> No manual entry for atf
> % grep -i tests /etc/src.conf
> WITHOUT_GOOGLETEST="YES"
> WITHOUT_TESTS="YES"

https://www.freebsd.org/cgi/man.cgi?query=atf

-- 
p...@opsec.eu+49 171 3101372Now what ?