Adding accessibility for blind and low vision individuals to OpenBSD?
Apologies if this is unnecessary sending of this, but I sent this to the tech OpenBSD mailing list (which might've not been the right list) so I'm re-sending it to this one just in case. (It might've gotten lost too.) The original email is below: So I've really wanted to try OpenBSD in a non-server configuration where I'm not installing over the internet on a remote server but on the local machine, but to my knowledge the OpenBSD installation media has no accessibility functionality whatsoever. (I'm not even sure if the installed system or any of the packages therein, such as in the ports collection, contains accessibility software.) Therefore, I'm wondering what it would take to add accessibility to the console portion of OpenBSD to begin with, as that as the simplest interface at the moment. The Orca screen reader may work on the desktop. There's a screen reader for the Linx console called Fenrir[1], but it may require functionality that is not available in OpenBSD, such as libevent. I've yet to try loading Fenrir on an installed OpenBSD system. Thoughts as to how this all could be achieved? I'm looking particular at screen readers; braille displays can be accomplished through something like brltty. [1]: https://github.com/chrys87/fenrir -- Signed, Ethin D. Probst
Re: Is there any way I can help with ath10k?
On Tue, Mar 23, 2021 at 03:13:38PM -0400, Brennan Vincent wrote: > I do not know how to write wifi drivers, but I am willing to donate hardware > or other resources if that would be helpful to someone. Please contact me if > so. I have a WIP driver which loads firmware but it can neither scan nor pass packets yet: https://git.stsp.in-berlin.de/gitweb/?p=openbsd-src.git;a=shortlog;h=refs/heads/athx There are more than enough cards in my stash which were supplied by the community. I would not mind sharing this hardware with other developers. I can collaborate if someone shows up who wants to work on this without needing a lot of my time for mentoring. Otherwise, I will pick this back up when I find time. At the moment there are other projects that are higher on my list. Cheers, Stefan
Is there any way I can help with ath10k?
I do not know how to write wifi drivers, but I am willing to donate hardware or other resources if that would be helpful to someone. Please contact me if so.
Re: /usr/bin/ld and /usr/bin/ld.lld
KAWAMATA Yoshihiro wrote:
> When I was looking at the snapshot package, I found that /usr/bin/ld
> and /usr/bin/ld.lld have the same contents and properties, but they
> are independent.
>
> Upon further investigation, it seems that this is due to the fact that
> /usr/bin/ld is contained in base69.tgz and /usr/bin/ld.ld is contained
> in comp69.tgz. It is likely that ld is included in base.tgz in order
> to run KARL.
>
> Since ld and ld.lld are identical, I think it would be preferable to
> include both in base.tgz. This will reduce the total size by about
> 40MB.
>
> If you build from the source tree, ld and ld.lld will be installed
> hard-linked.
Some other scripts need changes also.
Index: checkflist
===
RCS file: /cvs/src/distrib/sets/checkflist,v
retrieving revision 1.13
diff -u -p -u -r1.13 checkflist
--- checkflist 17 Apr 2017 19:44:59 - 1.13
+++ checkflist 23 Mar 2021 17:04:03 -
@@ -38,11 +38,11 @@ arch=`machine`
for i in base comp etc game man; do
cat ./lists/$i/mi ./lists/$i/md.${arch}
- if [ $i = comp ]; then
- [ -f ./lists/comp/gcc.${arch} ] && \
- cat ./lists/comp/gcc.${arch}
- [ -f ./lists/comp/clang.${arch} ] && \
- cat ./lists/comp/clang.${arch}
+ if [ $i = comp -o $i = base ]; then
+ [ -f ./lists/$i/gcc.${arch} ] && \
+ cat ./lists/$i/gcc.${arch}
+ [ -f ./lists/$i/clang.${arch} ] && \
+ cat ./lists/$i/clang.${arch}
fi
done | sort >$TMP1
Index: makelocatedb
===
RCS file: /cvs/src/distrib/sets/makelocatedb,v
retrieving revision 1.2
diff -u -p -u -r1.2 makelocatedb
--- makelocatedb18 Apr 2017 07:13:39 - 1.2
+++ makelocatedb23 Mar 2021 17:10:18 -
@@ -39,7 +39,7 @@ cd ${lists}
for i in base comp etc game man; do
{
case $i in
- comp)
+ base|comp)
[ -f $i/gcc.${arch} ] && cat $i/gcc.${arch}
[ -f $i/clang.${arch} ] && cat $i/clang.${arch}
;;
Index: maketars
===
RCS file: /cvs/src/distrib/sets/maketars,v
retrieving revision 1.26
diff -u -p -u -r1.26 maketars
--- maketars17 Apr 2017 19:44:59 - 1.26
+++ maketars23 Mar 2021 17:09:47 -
@@ -56,7 +56,7 @@ cd $fsdir
for i in base comp game man; do
echo -n "$i: "
cat ${lists}/$i/mi ${lists}/$i/md.${arch} > $TMP2
- if [ $i = comp ]; then
+ if [ $i = comp -o $i = base ]; then
[ -f ${lists}/$i/gcc.${arch} ] && \
cat ${lists}/$i/gcc.${arch} >> $TMP2
[ -f ${lists}/$i/clang.${arch} ] && \
Index: lists/base/clang.amd64
===
RCS file: lists/base/clang.amd64
diff -N lists/base/clang.amd64
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.amd64 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.arm64
===
RCS file: lists/base/clang.arm64
diff -N lists/base/clang.arm64
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.arm64 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.armv7
===
RCS file: lists/base/clang.armv7
diff -N lists/base/clang.armv7
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.armv7 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.i386
===
RCS file: lists/base/clang.i386
diff -N lists/base/clang.i386
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.i386 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.loongson
===
RCS file: lists/base/clang.loongson
diff -N lists/base/clang.loongson
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.loongson 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.macppc
===
RCS file: lists/base/clang.macppc
diff -N lists/base/clang.macppc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.macppc 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.octeon
===
RCS file: lists/base/clang.octeon
diff -N lists/base/clang.octeon
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.octeon 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.powerpc64
===
Re: /usr/bin/ld and /usr/bin/ld.lld
KAWAMATA Yoshihiro wrote:
> When I was looking at the snapshot package, I found that /usr/bin/ld
> and /usr/bin/ld.lld have the same contents and properties, but they
> are independent.
>
> Upon further investigation, it seems that this is due to the fact that
> /usr/bin/ld is contained in base69.tgz and /usr/bin/ld.ld is contained
> in comp69.tgz. It is likely that ld is included in base.tgz in order
> to run KARL.
>
> Since ld and ld.lld are identical, I think it would be preferable to
> include both in base.tgz. This will reduce the total size by about
> 40MB.
>
> If you build from the source tree, ld and ld.lld will be installed
> hard-linked.
true.
A diff to do that probably looks like the following. I will test it in
snapshots, and refine it if needed.
Index: checkflist
===
RCS file: /cvs/src/distrib/sets/checkflist,v
retrieving revision 1.13
diff -u -p -u -r1.13 checkflist
--- checkflist 17 Apr 2017 19:44:59 - 1.13
+++ checkflist 23 Mar 2021 17:04:03 -
@@ -38,11 +38,11 @@ arch=`machine`
for i in base comp etc game man; do
cat ./lists/$i/mi ./lists/$i/md.${arch}
- if [ $i = comp ]; then
- [ -f ./lists/comp/gcc.${arch} ] && \
- cat ./lists/comp/gcc.${arch}
- [ -f ./lists/comp/clang.${arch} ] && \
- cat ./lists/comp/clang.${arch}
+ if [ $i = comp -o $i = base ]; then
+ [ -f ./lists/$i/gcc.${arch} ] && \
+ cat ./lists/$i/gcc.${arch}
+ [ -f ./lists/$i/clang.${arch} ] && \
+ cat ./lists/$i/clang.${arch}
fi
done | sort >$TMP1
Index: lists/base/clang.amd64
===
RCS file: lists/base/clang.amd64
diff -N lists/base/clang.amd64
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.amd64 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.arm64
===
RCS file: lists/base/clang.arm64
diff -N lists/base/clang.arm64
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.arm64 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.armv7
===
RCS file: lists/base/clang.armv7
diff -N lists/base/clang.armv7
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.armv7 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.i386
===
RCS file: lists/base/clang.i386
diff -N lists/base/clang.i386
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.i386 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.loongson
===
RCS file: lists/base/clang.loongson
diff -N lists/base/clang.loongson
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.loongson 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.macppc
===
RCS file: lists/base/clang.macppc
diff -N lists/base/clang.macppc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.macppc 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.octeon
===
RCS file: lists/base/clang.octeon
diff -N lists/base/clang.octeon
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.octeon 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.powerpc64
===
RCS file: lists/base/clang.powerpc64
diff -N lists/base/clang.powerpc64
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.powerpc64 23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.sgi
===
RCS file: lists/base/clang.sgi
diff -N lists/base/clang.sgi
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.sgi23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/clang.sparc64
===
RCS file: lists/base/clang.sparc64
diff -N lists/base/clang.sparc64
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/clang.sparc6423 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.lld
Index: lists/base/gcc.alpha
===
RCS file: lists/base/gcc.alpha
diff -N lists/base/gcc.alpha
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lists/base/gcc.alpha23 Mar 2021 17:05:04 -
@@ -0,0 +1 @@
+./usr/bin/ld.bfd
Index: lists/base/gcc.amd64
===
/usr/bin/ld and /usr/bin/ld.lld
Hi, When I was looking at the snapshot package, I found that /usr/bin/ld and /usr/bin/ld.lld have the same contents and properties, but they are independent. Upon further investigation, it seems that this is due to the fact that /usr/bin/ld is contained in base69.tgz and /usr/bin/ld.ld is contained in comp69.tgz. It is likely that ld is included in base.tgz in order to run KARL. Since ld and ld.lld are identical, I think it would be preferable to include both in base.tgz. This will reduce the total size by about 40MB. If you build from the source tree, ld and ld.lld will be installed hard-linked. Yoshihiro Kawamata http://fuguita.org/
Re: Documentation on OpenBSD's 3-process privsep model?
On 23/03/2021 05:53, misopolemiac wrote: I'd appreciate some pointers to documentation or minimal examples of the 3-process privilege separation model for OpenBSD's daemons. Internet searches pointed to skeleton examples at github.com/krwesterback/newd and github.com/krwesterback/newdctl, but those repos are now dead and it's unclear how authoritative they were in the first place. Blind leading the blind here, but I think a good starting point would be recent presentations by Marc Espie, who, I believe but I might be wrong, is the developer who worked the most on privsep. http://www.openbsd.org/events.html -- Ottavio Caruso
Re: aggr+vlan lost packets
On 2021-03-22, Szél Gábor wrote:
> Dear List!
>
> We make some tests, i think this is intel em driver (82571EB) bug!
>
> * if i move aggr0 from em devices to bnx devices, everything will be fine!
> (only change trunkport from em to bnx)
> * if i change intel network card to other intel network card with
> 82571EB chipset, not working.
> * if i copy network interfaces config to another server (clear openbsd
> 6.8 install) with 6x Intel I210 network cards, everything will be fine!
> * if i move SSD from working intel configuration server (I210) to
> PE210 (82571EB), not working.
> * i tested with oBSD 6.7, the problem exists ., but before reinstall
> this server, on oBSD 6.1, LACP + 82571EB is working correctly.
>
> we have many-many OpenBSD (router, firewall) installations, but we have
> not yet experienced this problem. If possible, we use intel network cards.
>
First off, it would be helpful to provide ifconfig output (preferably
in full) and lacp status from the switch. This might give some clues
immediately..
One big difference between trunk and aggr is that trunk always uses
promiscuous mode, aggr doesn't (unless other software forces it).
This means that it relies on filters on the NIC (e.g. received
address filters / multicast filters) getting programmed correctly.
If this is caused by a NIC driver bug (or hardware bug not worked-
around properly by the driver) it's most likely in that area.
The NIC is normally (when not in promisc mode) programmed to
receive just packets sent to certain addresses. There's a small
table (receive address register RAR, 15 entries on this nic) where you
put a list of full destination MAC addresses to receive. If there are
a bunch of multicast addresses in use that exceeds this there's
another filter table used for these. Or it can be set to
"multicast promiscuous" where it uses the filter for normal traffic
but allows all multicast.
I'm not really a driver hacker but have an idea for one thing you
can try if nobody has a better idea. In if_em.c find this
1438 reg_rctl = E1000_READ_REG(&sc->hw, RCTL);
1439 reg_rctl &= ~(E1000_RCTL_MPE | E1000_RCTL_UPE);
1440 ifp->if_flags &= ~IFF_ALLMULTI;
1441
1442 if (ifp->if_flags & IFF_PROMISC || ac->ac_multirangecnt > 0 ||
1443 ac->ac_multicnt > MAX_NUM_MULTICAST_ADDRESSES) {
1444 ifp->if_flags |= IFF_ALLMULTI;
1445 reg_rctl |= E1000_RCTL_MPE;
1446 if (ifp->if_flags & IFF_PROMISC)
1447 reg_rctl |= E1000_RCTL_UPE;
1448 } else {
change 1442 to this
1442 if ( 1 || ifp->if_flags & IFF_PROMISC || ac->ac_multirangecnt > 0
||
and build/install a new kernel. This will stop it using the multicast
filter and instead accept all multicast packets. If this fixes things
then the problem is likely to be with the multicast filter programming,
it varies a bit between models and might have missed some special case.
If not then, well, at least it rules that out ..
Another big difference is that trunk uses the MAC address from a member
interface, aggr creates a random address by default (you can force it to
a particular address with "lladdr aa:bb:cc:dd:ee:ff"). There's clearly
some problem in this area with 82571 em worked around in if_em_hw.c
(around line 7547). (locally administered address = where the MAC has
been reset). Perhaps it's not handled completely.
Of course if you need it working there is also the option to use
trunk instead of aggr, or to run something (e.g. tcpdump) to force
the nic into promiscuous mode, but it would be nice to get this
figured out..
Re: Auto-mounting removable disks
On Tue, Mar 23, 2021 at 12:43:09AM +, tetrahe...@danwin1210.me wrote: > I have a removable disk that I want to auto-mount. However, it may not > always be present. If I put an entry in fstab for it, will the system be > able to cope even if the disk is not present? > > Is there a better way to do this? > https://vx21.xyz/automounting-usb-drives-openbsd/
Documentation on OpenBSD's 3-process privsep model?
I'd appreciate some pointers to documentation or minimal examples of the 3-process privilege separation model for OpenBSD's daemons. Internet searches pointed to skeleton examples at github.com/krwesterback/newd and github.com/krwesterback/newdctl, but those repos are now dead and it's unclear how authoritative they were in the first place.
Re: Resurrecting the Dead
Hi, thanks for the insightful article, I also really liked the VRF OpenVPN guide, I'll try to implement it with my VPN provider some day... I think you've got some really good content going on on your blog. Best regards Kristjan Komlosi On 3/21/21 6:34 PM, Lari Huttunen wrote: All, I wrote a short blog post on how to deal with dead OpenVPN tunnels. This may be an issue you have encountered as well, when connecting to a commercial VPN provider's servers on more or less permanent basis. The blunt instrument is detailed here: https://www.huttu.net/posts/openvpn-client-stability/ I would be interested in hearing about other more elegant solutions as well. :) Best regards, Lari Huttunen
Re: aggr+vlan lost packets
Dear List!
We make some tests, i think this is intel em driver (82571EB) bug!
* if i move aggr0 from em devices to bnx devices, everything will be fine!
(only change trunkport from em to bnx)
* if i change intel network card to other intel network card with
82571EB chipset, not working.
* if i copy network interfaces config to another server (clear openbsd
6.8 install) with 6x Intel I210 network cards, everything will be fine!
* if i move SSD from working intel configuration server (I210) to
PE210 (82571EB), not working.
* i tested with oBSD 6.7, the problem exists ., but before reinstall
this server, on oBSD 6.1, LACP + 82571EB is working correctly.
we have many-many OpenBSD (router, firewall) installations, but we have
not yet experienced this problem. If possible, we use intel network cards.
--
Üdvözlettel,
Szél Gábor
WanTax Kft.
tel.: +36 20 3838 171
fax: +36 82 357 585
email:gabor.s...@wantax.hu
web:http://wantax.hu
web:http://halozatom.hu
2021. 03. 22. 12:06 keltezéssel, Szél Gábor írta:
Dear List!
We have very interesting problem!
We are reinstalling a OpenBSD firewall (6.1 -> 6.8), and we connect
new servers to firewall.
We replaced firewall for the duration of the update, is not currently
production use.
Test configuration:
- Dell PE210 II (Firewall) 2x Broadcom BCM5716 (bnx) integrated for
WANs, 4x Intel 82571EB (em) PCIexp, for LANs
- Dell PE740 (Proxmox) - 2x 1G, 2x10G (currently 1G links) (node1)
- Dell PE740 (Proxmox) - 2x 1G, 2x10G (currently 1G links) (node2)
- Cisco 2960s-48ts-s switch
All devices connected to switch, witch LACP:
- firewall 4x em{0|1|2|3} - aggr0
- nodes 2x1G (eno)
- we configured only one VLAN, VLAN2 for managment (10.110.2.0/24)
- All device used tagged VLAN for managment. (but we tested, untaged,
native VLAN, no difference)
- no PF rules! clear OpenBSD install!
I describe the configurations at the end of the letter!
IPs:
- FW - 10.110.2.1 (on managment vlan if)
- switch - 10.110.2.11 (on managment vlan if)
- node 1 - 10.110.2.51 (on vmbr2 if tagged, or vmbr0 if untagged)
- node 1 - 10.110.2.52 (on vmbr2 if tagged, or vmbr0 if untagged)
Problem:
- all LACP is UP, no problems reported
- nodes see each other nodes
- nodes see switch managment VLAN IP address
- firewall see switch managment VLAN IP address
but,
- node 1 see firewall IP address
- node 2 NOT see firewall IP address
- if we changed bond parameters on nodes - from 2x10G network if to
2x1G network if, node 2 see friewall, node 1 NOT see firewall
(different MAC address)
interesting problem:
- if a start tcpdump on firewall vlan2 or aggr0 interface, everything
will be fine!!! if i stoped tcpdump, bad again! - what??? :)
- if node 2 have packet lost, i start tcpdump in node 2, a see ICMP
request, and reply packets from/to firewall!
We use a lot of oBSD 6.8 firewalls with LACP + VLANs, we have not
experienced this.
_
__Configurations:_
oBSD:
*/etc/hostname.aggr0 *
trunkport em0
trunkport em1
trunkport em2
trunkport em3
172.19.253.1 netmask 255.255.255.255
description "c1 LACP"
up
*/etc/hostname.vlan2*
inet 10.110.2.1 255.255.255.0 10.110.2.255 vnetid 2 parent aggr0
description "Managment"
*sysctl.conf*
net.inet.ip.forwarding=1 # 1=Permit forwarding (routing) of IPv4
packets
net.inet.carp.log=3 # log level of carp(4) info, default 2
machdep.kbdreset=1 # permit console CTRL-ALT-DEL to do a
nice halt
ddb.panic=0 # do not enter ddb console on kernel
panic, reboot if possible
kern.bufcachepercent=90 # Allow the kernel to use up to 90% of
the RAM for cache (default 10%)
net.inet.ip.forwarding=1 # Permit forwarding (routing) of
packets through the firewall
net.inet.ip.mtudisc=0 # TCP MTU (Maximum Transmission Unit)
discovery off since our mss is small enough
net.inet.tcp.rfc3390=1 # Enable RFC3390 TCP window increasing
so larger CWND can take affect
vm.swapencrypt.enable=1 # encrypt pages that go to swap
machdep.kbdreset=1 # permit console CTRL-ALT-DEL to do a
nice halt
hw.allowpowerdown=1 # 0=Disable power button shutdown
hw.smt=1 # HT
*Cisco 2960S
*interface Port-channel1
description FW
switchport mode trunk
switchport nonegotiate
!
interface Port-channel2
description n1.pve
switchport mode trunk
switchport nonegotiate
!
interface Port-channel3
description n2.pve
switchport mode trunk
switchport nonegotiate
!
interface GigabitEthernet0/1
description n1.pve
switchport mode trunk
switchport nonegotiate
spanning-tree portfast trunk
channel-group 2 mode active
!
interface GigabitEthernet0/2
description n1.pve
switchport mode trunk
switchport nonegotiate
spanning-tree portfast trunk
channel-group 2 mode active
!
interface GigabitEthernet0/3
description n2.pve
switchport mode trunk
switchport nonegotiate
channel-group 3 mode active
!
interface GigabitEthernet0/4
description n2.pve
switchport mode
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice, but I see you're using the ZZZ command to hibernate the system, yet it appears you want to suspend the system (based on wording). Have you tested zzz (lowercase) instead? Maybe your hardware/setup doesn't support hibernation. If you are indeed trying to hibernate, then I have nothing. Sorry. ‐‐‐ Original Message ‐‐‐ On Monday, March 22nd, 2021 at 8:20 AM, Mark Hesselink wrote: > Hi, > > I'm sending the below bug report to misc@openbsd.org as I have > > deliberately not configured my OpenBSD workstations to be able to send > > mail -- they are mostly used by my children -- and a bug report sent > > directly to b...@openbsd.org never seems to have arrived. Hopefully this > > email does arrive. > > Cheers, > > Mark > > --- > > > Synopsis: Suspend/resume does not work on Lenovo X2 Carbon 3rd gen > > laptop > > > Category: system > > > Environment: > > System : OpenBSD 6.9 > > Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 > > 15:01:24 MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > > Description: > > Suspend/resume unfortunately does not work on my Lenovo X1 Carbon > > 3rd gen laptop. Suspending the laptop using the ZZZ command does > > seem to suspend the laptop, but restarting the laptop afterwards > > does not result in the expected boot loader prompt of: > > >> OpenBSD/amd64 BOOT 3.53 > > unhibernate detected: switching to /bsd.booted > > boot> > > Instead a standard boot prompt is presented as if the laptop never > > completed the suspend request, but instead was abruptly shut down. > > During boot the system detects that 1 or more filesystems were not > > cleanly unmounted as well. > > I have tried playing around with the various TPM settings in the > > BIOS, i.e. disabled, hidden and enabled TPM. Neither of these > > settings seem to have an effects on the laptop's ability to cleanly > > suspend/resume. > > > How-To-Repeat: > > ZZZ followed by booting of the laptop. > > > Fix: > > No known work around. > > dmesg: > > OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8261603328 (7878MB) > > avail mem = 7995826176 (7625MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) > > bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 > > bios0: LENOVO 20BTS0MX00 > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT > > SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI > > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpihpet0 at acpi0: 14318179 Hz > > acpiec0 at acpi0 > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.63 MHz, 06-3d-04 > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu0: 256KB 64b/line 8-way L2 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > > cpu0: apic clock running at 99MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06-3d-04 > > cpu1: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu1: 256KB 64b/line 8-way L2 cache >
