Re: power of 2 revisited

[Jonathan Gray]

On Wed, Dec 29, 2021 at 09:27:34PM -0700, Ted Bullock wrote:
> This started out as a direct question to Ingo, but I have readdressed it
> to misc@
> 
> This is around documenting peculiar behaviour around power of 2 math in
> the kernel.
> 
> I noticed that in sys/dev/pci/drm/radeon/radeon_device.c:1137 there is a
> call to radeon_check_pot_argument, this function isn't correct in that
> it returns true for a value of zero (as you know, 0 is not a power of two).
> 
> I sent a diff to Jonathan to correct the behaviour which he rejected
> because he doesn't want to add local changes to change behaviour which
> isn't hitting a bug here. Fair Enough.
> 
> Then reading through old mail archives I came across this discussion
> from a few years back:
> https://marc.info/?t=14432152764&r=1&w=2
> 
> I'm wondering if it's worth documenting the peculiarities here, and
> possibly putting an actually mathematically correct check somewhere in
> the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED
> functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n).
> 
> Is this at all worthwhile? Maybe this would help stop people from
> incorrectly reinventing the wheel?
> 
> For instance in the kernel right now there is :
> radeon_check_pot_argument
> IS_POWER_OF_2
> is_power_of_2
> is_power_of_2_u64
> powerof2
> probably others too.

IS_POWER_OF_2 and is_power_of_2_u64 are inteldrm specific
is_power_of_2 is a linux interface.

radeon_check_pot_argument should be replaced in linux by
is_power_of_2.
https://lists.freedesktop.org/archives/amd-gfx/2021-December/073108.html

No code outside of drm should be using the linux interfaces and
I don't think we should be documenting them.

> 
> And manual checks like
> sys/arch/amd64/amd64/identcpu.c:804
> powerof2 = ((x - 1) & x) == 0;
> 
> -- 
> Ted Bullock 
> 
> 

power of 2 revisited

[Ted Bullock]

This started out as a direct question to Ingo, but I have readdressed it
to misc@

This is around documenting peculiar behaviour around power of 2 math in
the kernel.

I noticed that in sys/dev/pci/drm/radeon/radeon_device.c:1137 there is a
call to radeon_check_pot_argument, this function isn't correct in that
it returns true for a value of zero (as you know, 0 is not a power of two).

I sent a diff to Jonathan to correct the behaviour which he rejected
because he doesn't want to add local changes to change behaviour which
isn't hitting a bug here. Fair Enough.

Then reading through old mail archives I came across this discussion
from a few years back:
https://marc.info/?t=14432152764&r=1&w=2

I'm wondering if it's worth documenting the peculiarities here, and
possibly putting an actually mathematically correct check somewhere in
the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED
functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n).

Is this at all worthwhile? Maybe this would help stop people from
incorrectly reinventing the wheel?

For instance in the kernel right now there is :
radeon_check_pot_argument
IS_POWER_OF_2
is_power_of_2
is_power_of_2_u64
powerof2
probably others too.

And manual checks like
sys/arch/amd64/amd64/identcpu.c:804
powerof2 = ((x - 1) & x) == 0;

-- 
Ted Bullock 

Suspend/hibernate broken [upgrade: 6.9 to 7.0] (solution)

[Clint Pachl]

This is how I got suspend and hibernate working again on my Huawei
Matebook after upgrading to 7.0 release. I thought I'd share here in
case it helps someone else.


SYNOPSIS:

Initiating a "sleep" state blanks the screen and illuminates the
keyboard (indicating sleep is immenent); but the laptop would never go
to sleep. It would also never wake up. However, pressing the power
button cleanly shutdown the system.

After comparing the 7.0 dmesg with an older version (6.6), I noticed
this difference:

tpm0 at acpi0 TPM_ addr 0xfed40040/0x1000: timed out waiting for
validity

acpi(4) confirmed that the TPM does connect to the ACPI driver. The
kernel error message above is a good hint that the TPM could be
preventing suspend and hibernate.


SOLUTION #1:

I disabled TPM in the kernel at the boot prompt (i.e., boot -c). Within
UKC, "tpm" matched another device. I disabled TPM specifying the device
number (devno) of the tpm0 device.

  UKC> list tpm
  UKC> disable 433

If this is the solution for you, make it permanent using the kernel
configuration file, bsd.re-config(5).


SOLUTION #2:

There is a "TCM/TPM" setting in BIOS; I disabled it. Booting the
base 7.0 kernel (TPM enabled) also fixed "sleep" modes.

This is the solution I decided to use.


REQUEST FOR COMMENT:

I'm not sure if disabling TPM like this creates a security issue.
Please let me know if there are negative repercussions.

Also, is this a bug that should be reported to bugs@?


ACPI from 7.0 DMESG:

"ELAN2201" at acpi0 not configured
"INT0E0C" at acpi0 not configured
"INT33A1" at acpi0 not configured
"INT3400" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT344B" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"WDT0001" at acpi0 not configured
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI UEFI ECDT SSDT MSDM SSDT SSDT TPM2 SSDT
SSDT SSDT ASPT BOOT HPET APIC MCFG SSDT WSMT SSDT DBGP DBG2 SSDT SSDT
DMAR NHLT FPDT BGRT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4)
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpiac0 at acpi0: AC
unit online acpials0 at acpi0: ALSD acpibat0 at acpi0: BAT0 model
"BASE-BAT" serial 123456789 type Li oem "Kollur" acpibtn0 at acpi0:
LID_ acpibtn1 at acpi0: PWRB acpicmos0 at acpi0
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60),
C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0:
C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1
mwait.1), PSS acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus 1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus 2 (RP09)
acpipwrres0 at acpi0: WRST
acpipwrres1 at acpi0: WRST
acpipwrres10 at acpi0: WRST
acpipwrres11 at acpi0: WRST
acpipwrres12 at acpi0: WRST
acpipwrres13 at acpi0: WRST
acpipwrres14 at acpi0: WRST
acpipwrres15 at acpi0: WRST
acpipwrres16 at acpi0: WRST
acpipwrres17 at acpi0: WRST
acpipwrres18 at acpi0: WRST
acpipwrres19 at acpi0: WRST
acpipwrres2 at acpi0: WRST
acpipwrres3 at acpi0: WRST
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpipwrres6 at acpi0: WRST
acpipwrres7 at acpi0: WRST
acpipwrres8 at acpi0: WRST
acpipwrres9 at acpi0: WRST
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpitz0 at acpi0: critical temperature is 98 degC
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
tpm0 at acpi0 TPM_ addr 0xfed40040/0x1000: timed out waiting for
validity

Re: Starlabs Lite Mk IV support

[Chris Cappuccio]

Chris Narkiewicz [he...@ezaquarii.com] wrote:
> Hi,
> 
> Does anybody run OpenBSD on Starlabs Lite Mk IV laptop?
> 
> https://starlabs.systems/pages/labtop-mk-iv
> 
> I'm considering buing it as an everyday carry, but could not
> find any stories in a blogosphere.
> 
> Starlabs staff told me that they tested it with
> FreeBSD and found that I2C does not work. I'm also worried
> about WiFi.
> 

It shouldn't be hard for them to do a spin with OpenBSD 7.0
or OpenBSD-current and send you a dmesg. That would help.

The AX201 is supported under OpenBSD in 802.11n mode.
802.11ac/ax requires some further improvements in the net80211
stack, but I suspect we aren't far off.

This laptop looks basically supported already. There are
possibly issues in the suspend/resume department, or custom
buttons for whatever purpose, they might need some support
code. 

Chris

Re: IPv6 autoconf with static IID?

[Mike Fischer]

Ok, ignore my previous mail. The solution is to use -soii:
# ifconfig em0 autoconf eui64 -soii lladdr f2:b6:71:e6:11:7e

This makes the non temporary public and ULA addresses use the EUI-64 IID based 
on the lladdr.


Thanks!

Mike

> Am 29.12.2021 um 19:37 schrieb Mike Fischer :
> 
> On Tue, Dec 28, 2021, at 21:05, Mike Fischer wrote:
>>> Am 28.12.2021 um 13:09 schrieb Paul de Weerd :
>>> Seems like the simplest way, especially using the lladdr option.
>> Yes, I’ll give that a try.
> 
> Ok, I have tried the following:
> 
> Remove my current IPv6 configuration from em0:
> # ifconfig em0 -inet6
> Test the new configuration:
> # ifconfig em0 inet6 autoconf eui64 lladdr f2:b6:71:e6:11:7e
> 
> This results in:
> - The interface em0 has the expected lladr of f2:b6:71:e6:11:7e
> - The link local IPv6 address is: fe80::f0b6:71ff:fee6:117e (using the 
> modified EUI-64 version of the lladdr) as expected
> - The public IPv4 IPs use my current prefix and a random IID, no relation to 
> the lladdr: 2001:db8::eb7f:1267:44d0:45a4 (*)
> - The ULA addresses behave the same as the public ones, i.e. the IID has not 
> relation to the lladdr.
> 
> Why is (one of) the public addresses not using the EUI-64 method of 
> generation the IID?
> 
> I realize that autoconf generates the SOII addresses with random IIDs. But 
> shouldn’t the eui64 option also create an IP with the modified EUI-64 as the 
> IID?
> 
> ifconfig(8) states:
> eui64  Fill the interface index (the lowermost 64 bits of an IPv6 address) 
> automatically.
> 
> Which is kind of a bland statement anyway. It should IMHO reference that a 
> modified EUI-64 is used. But it does not say that this is only true for the 
> link local address.
> 
> 
> If have tried changing the order of the parameters, but it makes no 
> difference:
> ifconfig em0 inet6 autoconf lladdr f2:b6:71:e6:11:7e eui64
> ifconfig em0 inet6 lladdr f2:b6:71:e6:11:7e eui64 autoconf
> 
> I have also tried to do this without the lladdr parameter, same results just 
> with a different lladdr.
> 
> If I leave out the autoconf parameter I only get a link local address.
> 
> 
> *) I have substituted 2001:db8:: for the real public prefix here.
> 
> 
> Thanks!
> 
> Mike

Re: IPv6 autoconf with static IID?

[Mike Fischer]

On Tue, Dec 28, 2021, at 21:05, Mike Fischer wrote:
>> Am 28.12.2021 um 13:09 schrieb Paul de Weerd :
>> Seems like the simplest way, especially using the lladdr option.
> Yes, I’ll give that a try.

Ok, I have tried the following:

Remove my current IPv6 configuration from em0:
# ifconfig em0 -inet6
Test the new configuration:
# ifconfig em0 inet6 autoconf eui64 lladdr f2:b6:71:e6:11:7e

This results in:
- The interface em0 has the expected lladr of f2:b6:71:e6:11:7e
- The link local IPv6 address is: fe80::f0b6:71ff:fee6:117e (using the modified 
EUI-64 version of the lladdr) as expected
- The public IPv4 IPs use my current prefix and a random IID, no relation to 
the lladdr: 2001:db8::eb7f:1267:44d0:45a4 (*)
- The ULA addresses behave the same as the public ones, i.e. the IID has not 
relation to the lladdr.

Why is (one of) the public addresses not using the EUI-64 method of generation 
the IID?

I realize that autoconf generates the SOII addresses with random IIDs. But 
shouldn’t the eui64 option also create an IP with the modified EUI-64 as the 
IID?

ifconfig(8) states:
eui64  Fill the interface index (the lowermost 64 bits of an IPv6 address) 
automatically.

Which is kind of a bland statement anyway. It should IMHO reference that a 
modified EUI-64 is used. But it does not say that this is only true for the 
link local address.


If have tried changing the order of the parameters, but it makes no difference:
ifconfig em0 inet6 autoconf lladdr f2:b6:71:e6:11:7e eui64
ifconfig em0 inet6 lladdr f2:b6:71:e6:11:7e eui64 autoconf

I have also tried to do this without the lladdr parameter, same results just 
with a different lladdr.

If I leave out the autoconf parameter I only get a link local address.


*) I have substituted 2001:db8:: for the real public prefix here.


Thanks!

Mike

Apply for a new community group

[Boling Hanjingxue]

Hi,

I am Hanjingxue from a newly established 
openBSD community, and we are building a Chinese openBSD 
community. We would like that the 
openBSD project will add the “openBSD 中文结社” to the list of OpenBSD User Groups 
as well.

Sincerely,
Hanjingxue Boling.



Detailed information:
0
C China
P Bejing
T Chaoyang
F Irregular
O OpenBSD Chinese Association
I BearChild
M zh-open...@protonmail.com
U https://github.com/openbsd-zh-association
N OpenBSD|*BSD
0
C China
P Bejing
T Chaoyang
F Irregular
O OpenBSD Chinese Association
I BearChild
M zh-open...@protonmail.com
U https://github.com/openbsd-zh-association
N OpenBSD|*BSD