Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)
On Tue, Aug 11, 2020 at 02:07:32PM -0400, Winfred Harrelson wrote: > I know others are using the new aggr(4) interface but I am having a > problem with trying to use it on some new servers I have recently > gotten. Hoping I could get some help from someone here since my > searches have not been very fruitful. > > First off this is on a Supermicro X11DPi-N(T) and it is running a 6.7 > snapshot from today because the 6.7 release hangs on trying to install. > > I have two Intel duel port XXV710 cards with SPF28 and trying to > create an LACP bond. Works fine using the trunk(4) interface but > not the aggr(4) interface. This is what I get: > > styx# ifconfig ixl0 > ixl0: flags=8843 mtu 1500 > lladdr fe:e1:ba:d0:cc:aa > index 1 priority 0 llprio 3 > trunk: trunkdev aggr1 ^ ixl0 is already member of aggr1 > media: Ethernet autoselect (25GbaseSR full-duplex) > status: active > styx# ifconfig ixl2 > ixl2: flags=8843 mtu 1500 > lladdr fe:e1:ba:d0:cc:aa > index 3 priority 0 llprio 3 > trunk: trunkdev aggr1 ^ same here > media: Ethernet autoselect (25GbaseSR full-duplex) > status: active > > So everything looks good. Now to create the bond: > > styx# ifconfig aggr0 create > styx# ifconfig aggr0 trunkport ixl0 > styx# ifconfig aggr0 trunkport ixl2 > styx# ifconfig aggr0 up > here you add them to aggr0. have you checked if aggr1 is operational? > No error message so that seems good, however when I look at the bond > I get "no carrier": > > styx# ifconfig aggr0 > aggr0: flags=8843 mtu 1500 > lladdr fe:e1:ba:d1:7d:55 > index 13 priority 0 llprio 7 > trunk: trunkproto lacp > trunk id: [(8000,fe:e1:ba:d1:7d:55,000D,,), > (,00:00:00:00:00:00,,,)] > ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d1:7d:55, key > 0xd, port pri 0x8000 number 0x1 > ixl0 lacp actor state activity,aggregation,defaulted > ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key > 0x0, port pri 0x0 number 0x0 > ixl0 lacp partner state activity,aggregation,sync > ixl0 port > ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d1:7d:55, key > 0xd, port pri 0x8000 number 0x3 > ixl2 lacp actor state activity,aggregation,defaulted > ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key > 0x0, port pri 0x0 number 0x0 > ixl2 lacp partner state activity,aggregation,sync > ixl2 port > groups: aggr > media: Ethernet autoselect > status: no carrier > > If I add debug to the ifconfig this is all I get in messages: > > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 trunkport: creating port > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 mux: BEGIN (BEGIN) -> DETACHED > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: BEGIN (BEGIN) -> INITIALIZE > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: INITIALIZE (UCT) -> PORT_DISABLED > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: PORT_DISABLED (port_enabled) -> > LACP_DISABLED > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 trunkport: creating port > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 mux: BEGIN (BEGIN) -> DETACHED > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: BEGIN (BEGIN) -> INITIALIZE > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: INITIALIZE (UCT) -> PORT_DISABLED > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: PORT_DISABLED (port_enabled) -> > LACP_DISABLED > Aug 11 13:45:48 styx /bsd: aggr0 ixl0 rxm: LACP_DISABLED (LACP_Enabled) -> > PORT_DISABLED > Aug 11 13:45:48 styx /bsd: aggr0 ixl0 rxm: PORT_DISABLED (port_enabled) -> > EXPIRED > Aug 11 13:45:48 styx /bsd: aggr0 ixl2 rxm: LACP_DISABLED (LACP_Enabled) -> > PORT_DISABLED > Aug 11 13:45:48 styx /bsd: aggr0 ixl2 rxm: PORT_DISABLED (port_enabled) -> > EXPIRED > Aug 11 13:45:51 styx /bsd: aggr0 ixl0 rxm: EXPIRED (current_while_timer > expired) -> DEFAULTED > Aug 11 13:45:51 styx /bsd: aggr0 ixl0: selection logic: unselected (rxm > !CURRENT) > Aug 11 13:45:51 styx /bsd: aggr0 ixl2 rxm: EXPIRED (current_while_timer > expired) -> DEFAULTED > Aug 11 13:45:51 styx /bsd: aggr0 ixl2: selection logic: unselected (rxm > !CURRENT) > > > Only thing I have found so far is a few threads from Nov - Dec 2019: > > https://marc.info/?l=openbsd-misc=157641049328878=2 > https://marc.info/?l=openbsd-misc=157537227501920=2 > https://marc.info/?l=openbsd-misc=157374699108084=2 > > > As with the above threads this works fine using the trunk(4) interface > just not the newer aggr(4) interface. > > They are connected to a Cisco Nexus 9508 switch. Any ideas of what > I can try? dmesg below > > Thanks > > Winfred > > > > stem subclass miscellaneous, rev 0x07) at pci4 dev 8 function 6 not configured > vendor "Intel", unknown product 0x208d (class system subclass miscellaneous, > rev 0x07) at
Re: laptop cpu high temperature while idle
o...@mailo.com wrote: $ sysctl hw.sensors | grep temp hw.sensors.cpu0.temp0=95.00 degC hw.sensors.acpitz0.temp0=79.00 degC (zone temperature) I have an old (of course) IBM/Lenovo X60 with a similar issue. Once it gets to 80 or 90C, the CPU goes into thermal runaway, emits a "exceeded 128C" syslog error and autoshuts down. I tried replacing the CPU paste, with little effect. So now it has: $ cat /etc/sysctl.conf hw.setperf=1 and the cpu runs at 1GHz instead of 1.6GHz and seems to stay cool even when working the CPU and graphics hard. John
aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)
I know others are using the new aggr(4) interface but I am having a problem with trying to use it on some new servers I have recently gotten. Hoping I could get some help from someone here since my searches have not been very fruitful. First off this is on a Supermicro X11DPi-N(T) and it is running a 6.7 snapshot from today because the 6.7 release hangs on trying to install. I have two Intel duel port XXV710 cards with SPF28 and trying to create an LACP bond. Works fine using the trunk(4) interface but not the aggr(4) interface. This is what I get: styx# ifconfig ixl0 ixl0: flags=8843 mtu 1500 lladdr fe:e1:ba:d0:cc:aa index 1 priority 0 llprio 3 trunk: trunkdev aggr1 media: Ethernet autoselect (25GbaseSR full-duplex) status: active styx# ifconfig ixl2 ixl2: flags=8843 mtu 1500 lladdr fe:e1:ba:d0:cc:aa index 3 priority 0 llprio 3 trunk: trunkdev aggr1 media: Ethernet autoselect (25GbaseSR full-duplex) status: active So everything looks good. Now to create the bond: styx# ifconfig aggr0 create styx# ifconfig aggr0 trunkport ixl0 styx# ifconfig aggr0 trunkport ixl2 styx# ifconfig aggr0 up No error message so that seems good, however when I look at the bond I get "no carrier": styx# ifconfig aggr0 aggr0: flags=8843 mtu 1500 lladdr fe:e1:ba:d1:7d:55 index 13 priority 0 llprio 7 trunk: trunkproto lacp trunk id: [(8000,fe:e1:ba:d1:7d:55,000D,,), (,00:00:00:00:00:00,,,)] ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d1:7d:55, key 0xd, port pri 0x8000 number 0x1 ixl0 lacp actor state activity,aggregation,defaulted ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 0x0, port pri 0x0 number 0x0 ixl0 lacp partner state activity,aggregation,sync ixl0 port ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d1:7d:55, key 0xd, port pri 0x8000 number 0x3 ixl2 lacp actor state activity,aggregation,defaulted ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 0x0, port pri 0x0 number 0x0 ixl2 lacp partner state activity,aggregation,sync ixl2 port groups: aggr media: Ethernet autoselect status: no carrier If I add debug to the ifconfig this is all I get in messages: Aug 11 13:45:37 styx /bsd: aggr0 ixl0 trunkport: creating port Aug 11 13:45:37 styx /bsd: aggr0 ixl0 mux: BEGIN (BEGIN) -> DETACHED Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: BEGIN (BEGIN) -> INITIALIZE Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: INITIALIZE (UCT) -> PORT_DISABLED Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: PORT_DISABLED (port_enabled) -> LACP_DISABLED Aug 11 13:45:44 styx /bsd: aggr0 ixl2 trunkport: creating port Aug 11 13:45:44 styx /bsd: aggr0 ixl2 mux: BEGIN (BEGIN) -> DETACHED Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: BEGIN (BEGIN) -> INITIALIZE Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: INITIALIZE (UCT) -> PORT_DISABLED Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: PORT_DISABLED (port_enabled) -> LACP_DISABLED Aug 11 13:45:48 styx /bsd: aggr0 ixl0 rxm: LACP_DISABLED (LACP_Enabled) -> PORT_DISABLED Aug 11 13:45:48 styx /bsd: aggr0 ixl0 rxm: PORT_DISABLED (port_enabled) -> EXPIRED Aug 11 13:45:48 styx /bsd: aggr0 ixl2 rxm: LACP_DISABLED (LACP_Enabled) -> PORT_DISABLED Aug 11 13:45:48 styx /bsd: aggr0 ixl2 rxm: PORT_DISABLED (port_enabled) -> EXPIRED Aug 11 13:45:51 styx /bsd: aggr0 ixl0 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED Aug 11 13:45:51 styx /bsd: aggr0 ixl0: selection logic: unselected (rxm !CURRENT) Aug 11 13:45:51 styx /bsd: aggr0 ixl2 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED Aug 11 13:45:51 styx /bsd: aggr0 ixl2: selection logic: unselected (rxm !CURRENT) Only thing I have found so far is a few threads from Nov - Dec 2019: https://marc.info/?l=openbsd-misc=157641049328878=2 https://marc.info/?l=openbsd-misc=157537227501920=2 https://marc.info/?l=openbsd-misc=157374699108084=2 As with the above threads this works fine using the trunk(4) interface just not the newer aggr(4) interface. They are connected to a Cisco Nexus 9508 switch. Any ideas of what I can try? dmesg below Thanks Winfred stem subclass miscellaneous, rev 0x07) at pci4 dev 8 function 6 not configured vendor "Intel", unknown product 0x208d (class system subclass miscellaneous, rev 0x07) at pci4 dev 8 function 7 not configured vendor "Intel", unknown product 0x208d (class system subclass miscellaneous, rev 0x07) at pci4 dev 9 function 0 not configured vendor "Intel", unknown product 0x208d (class system subclass miscellaneous, rev 0x07) at pci4 dev 9 function 1 not configured vendor "Intel", unknown product 0x208d (class system subclass miscellaneous, rev 0x07) at pci4 dev 9 function 2 not configured vendor "Intel", unknown product 0x208d (class system
Adding more syspatch platform.
Just a general question as I got to really love syspatch and sysupgrade to the point that oppose to before, now my platforms are pretty much always up to date and patch in just a few days after patches are release or even in some cases the same day. To add more platform, I guess that mean man power right, or is that an hardware issue? Not a complain at all, I love where we are, just a real generic question and if that's a hardware issue, I think there is more then that, I would be happy to contribute some if that help. If more then that, I apologies for the question. Many thanks for all you do! Greatly appreciated! Daniel
019_libssl.patch regression
This is a regression report for 019_libssl.patch predrag@oko$ uname -a OpenBSD oko.int.bagdala2.net 6.7 GENERIC.MP#5 amd64 predrag@oko$ syspatch -l 001_wscons 002_rpki 003_ssh 004_libssl 005_unbound 006_smtpd_sockaddr 007_perl 008_hid 009_asr 010_x509 011_shmget 012_tty 013_tty 014_iked 015_rpki 016_ximcp 017_dix 018_ximcp 019_libssl After applying libssl binary patch to 6.7 release s-nail-14.9.19 can no longer close STARTTLS IPMI session with Gmail server. I recompiled s-nail and rebooted the machine. After reverting the patch s-nail works as expected. Interestingly enough I can only see this with Gmail servers. 019_libssl.patch doesn't break Hotmail IPMI connection. Patch does break SMTP session with Gmail server in the same fashion as IPMI. It just doesn't terminate cleanly. I don't know enough about the subject to look further into the problem but I am 100% sure this is LibreSSL bug. Best, Predrag
Re: Adding more syspatch platform.
No, it is a question of which additional platform, you avoided that didn't you if you name one that less than 100 people use, then well come on Daniel Ouellet wrote: > Just a general question as I got to really love syspatch and sysupgrade > to the point that oppose to before, now my platforms are pretty much > always up to date and patch in just a few days after patches are release > or even in some cases the same day. > > To add more platform, I guess that mean man power right, or is that an > hardware issue? > > Not a complain at all, I love where we are, just a real generic question > and if that's a hardware issue, I think there is more then that, I would > be happy to contribute some if that help. > > If more then that, I apologies for the question. > > Many thanks for all you do! Greatly appreciated! > > Daniel >
Re: wireguard listen in other rdomain?
On Tue, Aug 11, 2020 at 6:22 PM Matt Dunwoodie wrote: > On Tue, 11 Aug 2020 17:46:05 -0500 > Abel Abraham Camarillo Ojeda wrote: > > > Hi to all, > > > > (unsure if this if for tech@ or misc@) > > Probably better suited for misc, moved there. > > > I'm using wireguard interfaces but I see that no matter what > > domain I put the interface: > > > > # ifconfig wg0 rdomain X > > > > It always listens in rdomain 0 (default), > > is this expected?, is there any way to listen in another rdomain? > > I want to expose several wg interfaces all listening in same port but > > there's not option to listen in another ip address: > > > > wgport port > > Set the UDP port that the tunnel operates on. The > > interface will > > bind to INADDR_ANY and IN6ADDR_ANY_INIT. If no port is > > configured, one will be chosen automatically. > > > > I tried creating several wg interfaces with different wgport and using > > pf udp redirections but source address selection gets very messy... > > > > Ideas? > > Have a look at "wgrtable" in ifconfig(8) to listen in another rdomain. > Thanks, will check that. > > However, I'd like to know the reason for wanting multiple interfaces > I made the original mail just from memory, but after reviewing the machine in question I realized that what I really wanted to do was having a single wg interface listen in several ports I run on this machine some services that are hard to isolate with pf so I run them in another rdomain (nfsd) and was exploring into how to make all this work + wg > and why they should be listening on the same port. I'm worried about extreme firewalls by universities/hotels and such here (Mexico) that block most ports, so I just recalled that what I really wanted was having a single wg interface listen in several of probably opened ports like: udp 4500 udp 53 (wanted to listen on udp53 on uplink interface/rdomain because I'm using udp53 in rdomain 0 for internal dns resolver) udp 123 (ntp) udp 443 (quic?) > Perhaps there is > a better solution than rdomains and pf redirections. > Sorry for this poorly described mail, maybe I need some sleep... Will try to answer this better tomorrow Thanks for your attention, I left that machine with a very fragile/complex setup that I'm having problems understanding right now... > Cheers, > Matt >
Re: Adding more syspatch platform.
Jordan Geoghegan wrote: > On 2020-08-11 15:50, Theo de Raadt wrote: > > Predrag Punosevac wrote: > > > >> Theo de Raadt wrote: > >> > >>> No, it is a question of which additional platform, you avoided that > >>> didn't you > >>> > >> octeon is the only one I can think of. > > read below: > > > >>> if you name one that less than 100 people use, then well come on > > Not that it matters, but I have well over 100 users of OpenBSD on > octeon for the different client sites I manage. I'd love to see > syspatches for octeon, but I have no business telling you guys what to > do. The people involved in building the syspatches don't even have octeons.
Re: Adding more syspatch platform.
On 2020-08-11 15:50, Theo de Raadt wrote: Predrag Punosevac wrote: Theo de Raadt wrote: No, it is a question of which additional platform, you avoided that didn't you octeon is the only one I can think of. read below: if you name one that less than 100 people use, then well come on Not that it matters, but I have well over 100 users of OpenBSD on octeon for the different client sites I manage. I'd love to see syspatches for octeon, but I have no business telling you guys what to do. Regards, Jordan
Re: Adding more syspatch platform.
Theo de Raadt wrote: > > No, it is a question of which additional platform, you avoided that > didn't you > octeon is the only one I can think of. arm64 binary patches are available for few releases already. The binary patches might be the least of the troubles on that platform. https://marc.info/?l=openbsd-misc=157716525114361=2 Predrag > > if you name one that less than 100 people use, then well come on > > > > > > Daniel Ouellet wrote: > > > Just a general question as I got to really love syspatch and sysupgrade > > to the point that oppose to before, now my platforms are pretty much > > always up to date and patch in just a few days after patches are release > > or even in some cases the same day. > > > > To add more platform, I guess that mean man power right, or is that an > > hardware issue? > > > > Not a complain at all, I love where we are, just a real generic question > > and if that's a hardware issue, I think there is more then that, I would > > be happy to contribute some if that help. > > > > If more then that, I apologies for the question. > > > > Many thanks for all you do! Greatly appreciated! > > > > Daniel > >
Re: wireguard listen in other rdomain?
On Tue, 11 Aug 2020 17:46:05 -0500 Abel Abraham Camarillo Ojeda wrote: > Hi to all, > > (unsure if this if for tech@ or misc@) Probably better suited for misc, moved there. > I'm using wireguard interfaces but I see that no matter what > domain I put the interface: > > # ifconfig wg0 rdomain X > > It always listens in rdomain 0 (default), > is this expected?, is there any way to listen in another rdomain? > I want to expose several wg interfaces all listening in same port but > there's not option to listen in another ip address: > > wgport port > Set the UDP port that the tunnel operates on. The > interface will > bind to INADDR_ANY and IN6ADDR_ANY_INIT. If no port is > configured, one will be chosen automatically. > > I tried creating several wg interfaces with different wgport and using > pf udp redirections but source address selection gets very messy... > > Ideas? Have a look at "wgrtable" in ifconfig(8) to listen in another rdomain. However, I'd like to know the reason for wanting multiple interfaces and why they should be listening on the same port. Perhaps there is a better solution than rdomains and pf redirections. Cheers, Matt
Re: Adding more syspatch platform.
On 2020-08-11 20:35, Theo de Raadt wrote: Jordan Geoghegan wrote: On 2020-08-11 15:50, Theo de Raadt wrote: Predrag Punosevac wrote: Theo de Raadt wrote: No, it is a question of which additional platform, you avoided that didn't you octeon is the only one I can think of. read below: if you name one that less than 100 people use, then well come on Not that it matters, but I have well over 100 users of OpenBSD on octeon for the different client sites I manage. I'd love to see syspatches for octeon, but I have no business telling you guys what to do. The people involved in building the syspatches don't even have octeons. I'd be happy to donate a couple of octeon machines if access to hardware is an issue. I'm just a random internet person, so I imagine you guys wouldn't trust me to do the work to build the syspatches, but please do let me know if some octeon machines would be useful to you guys. I'd happily do the legwork myself but there doesn't appear to be a way to manually syspatch (please correct me if I'm wrong). Regards, Jordan
Re: X11 VESA Driver Config Question
I just upgraded from 6.6 to snapshot via sysupgrade -s After reboot I get the various emails the upgrade goes fine, no errors, the firmware is upgraded. About 30 seconds after I get the login prompt the laptop powers off. I turned in on and at the boot prompt typed boot -c and disable amdgpu Subjectively I got more than 30 seconds after the boot prompt. I was able to log in and look around a bit and it powered off. Same thing with booting into single user mode. Thoughts? Suggestions on how to get any data? Jon On Mon, 10 Aug 2020 20:28:34 -0500 Chris Bennett wrote: > On Sun, Aug 09, 2020 at 10:02:24PM -0400, Jon Fineman wrote: > > I have an Acer Aspire A315 laptop that freezes every once in a > > while. I think it is GPU related, but have not been able to get any > > logs. In addition a while ago (roughly when 6.7 came out) I tried > > to upgrade from 6.6 to 6.7 and the laptop would turn off just after > > getting the log in prompt. Again no logs. > > > > One thought was in my xorg.conf file to change the driver from > > AMDGPU to vesa. However that is producing an error. Log and dmesg > > below. > > > > Any thoughts on how to proceed? > > > > There is an excellent chance that we have the same problem. > I was running -current for a long while, when I had the same problem > with sudden unexpected shutdown. This was a good while back. > I have 50GB of install66.iso from current back then. They are on one > of my servers. Unfortunately, I just don't have access to enough > bandwidth or data to download them to hopefully find the date that > there was a change that messed things up. > > Try boot -c then disable amdgpu > Might help. Also try boot -s and wait. If it shuts down there too, > probably have the same problem. Or not. :-) > > I'm stuck at 6.6 -stable for now. > > Chris Bennett > > > > Thnaks. > > > > Jon > > > > > > xorg.conf: > > Section "Device" > > Identifier "graphicsdriver" > > #Driver "AMDGPU" > > #Option "TearFree" "true" > > Driver "vesa" > > EndSection > > > > > > > > Xorg.0.log: > > [124569.415] (--) checkDevMem: using aperture driver /dev/xf86 > > [124569.425] (--) Using wscons driver on /dev/ttyC4 > > [124569.446] > > X.Org X Server 1.20.5 > > X Protocol Version 11, Revision 0 > > [124569.446] Build Operating System: OpenBSD 6.6 amd64 > > [124569.446] Current Operating System: OpenBSD laptop.jonjfineman.me > > 6.6 GENERIC.MP#3 amd64 [124569.447] Build Date: 30 July 2020 > > 11:25:30AM [124569.447] > > [124569.447] Current version of pixman: 0.38.4 > > [124569.447]Before reporting problems, check > > http://wiki.x.org to make sure that you have the latest version. > > [124569.447] Markers: (--) probed, (**) from config file, (==) > > default setting, (++) from command line, (!!) notice, (II) > > informational, (WW) warning, (EE) error, (NI) not implemented, (??) > > unknown. [124569.447] (==) Log file: "/var/log/Xorg.0.log", Time: > > Sun Aug 9 05:48:55 2020 [124569.447] (==) Using config file: > > "/etc/X11/xorg.conf" [124569.447] (==) Using system config directory > > "/usr/X11R6/share/X11/xorg.conf.d" [124569.447] (==) No Layout > > section. Using the first Screen section. [124569.447] (==) No > > screen section available. Using defaults. [124569.447] (**) > > |-->Screen "Default Screen Section" (0) [124569.447] (**) | > > |-->Monitor "" [124569.448] (==) No device > > specified for screen "Default Screen Section". Using the first > > device section listed. [124569.448] (**) | |-->Device > > "graphicsdriver" [124569.448] (==) No monitor specified for screen > > "Default Screen Section". Using a default monitor configuration. > > [124569.448] (==) Automatically adding devices > > [124569.448] (==) Automatically enabling devices > > [124569.448] (==) Not automatically adding GPU devices > > [124569.448] (==) Max clients allowed: 256, resource mask: 0x1f > > [124569.448] (==) FontPath set to: > > /usr/X11R6/lib/X11/fonts/misc/, > > /usr/X11R6/lib/X11/fonts/TTF/, > > /usr/X11R6/lib/X11/fonts/OTF/, > > /usr/X11R6/lib/X11/fonts/Type1/, > > /usr/X11R6/lib/X11/fonts/100dpi/, > > /usr/X11R6/lib/X11/fonts/75dpi/ > > [124569.448] (==) ModulePath set to "/usr/X11R6/lib/modules" > > [124569.448] (II) The server relies on wscons to provide the list of > > input devices. If no devices become available, reconfigure wscons or > > disable AutoAddDevices. [124569.448] (II) Loader magic: > > 0xc3982ca3000 [124569.448] (II) Module ABI versions: > > [124569.448]X.Org ANSI C Emulation: 0.4 > > [124569.448]X.Org Video Driver: 24.0 > > [124569.448]X.Org XInput driver : 24.1 > > [124569.448]X.Org Server Extension : 10.0 > > [124569.448] (--) PCI:*(0@0:1:0) 1002:98e4:1025:1192 rev 218, Mem @ > > 0xe000/268435456, 0xf000/8388608, 0xf0d0/262144, I/O @ > > 0x3000/256, BIOS @ 0x/131072 [124569.448] (II) > > LoadModule: "glx" [124569.449] (II) Loading > >
Re: Adding more syspatch platform.
Predrag Punosevac wrote: > Theo de Raadt wrote: > > > > > No, it is a question of which additional platform, you avoided that > > didn't you > > > > octeon is the only one I can think of. read below: > > if you name one that less than 100 people use, then well come on
Re: X11 VESA Driver Config Question
On Tue, Aug 11, 2020 at 08:17:01PM -0400, Jon Fineman wrote:
> I just upgraded from 6.6 to snapshot via sysupgrade -s
>
> After reboot I get the various emails the upgrade goes fine, no errors,
> the firmware is upgraded.
>
> About 30 seconds after I get the login prompt the laptop powers off.
>
> I turned in on and at the boot prompt typed boot -c and disable amdgpu
> Subjectively I got more than 30 seconds after the boot prompt. I was
> able to log in and look around a bit and it powered off.
>
> Same thing with booting into single user mode.
>
> Thoughts? Suggestions on how to get any data?
>
> Jon
>
sysctl.conf needs
machdep.allowaperture=2
if you can't mount from another computer, burn 6.6 onto a USB stick and
mount from that. Don't even try from running -current.
You can probably get /var/run/dmesg.boot. Plus /var/log/Xorg.0.log if
you manage to get to X. (Good luck with that :-{ )
I was given advice in the past to build with a certain change, but I was
unable to build that on my laptop due to very little memory.
There is newer firmware, X, etc.. Hopefully someone will chime in with
something to try for a build
Chris Bennett
>
>
> On Mon, 10 Aug 2020 20:28:34 -0500
> Chris Bennett wrote:
>
> > On Sun, Aug 09, 2020 at 10:02:24PM -0400, Jon Fineman wrote:
> > > I have an Acer Aspire A315 laptop that freezes every once in a
> > > while. I think it is GPU related, but have not been able to get any
> > > logs. In addition a while ago (roughly when 6.7 came out) I tried
> > > to upgrade from 6.6 to 6.7 and the laptop would turn off just after
> > > getting the log in prompt. Again no logs.
> > >
> > > One thought was in my xorg.conf file to change the driver from
> > > AMDGPU to vesa. However that is producing an error. Log and dmesg
> > > below.
> > >
> > > Any thoughts on how to proceed?
> > >
> >
> > There is an excellent chance that we have the same problem.
> > I was running -current for a long while, when I had the same problem
> > with sudden unexpected shutdown. This was a good while back.
> > I have 50GB of install66.iso from current back then. They are on one
> > of my servers. Unfortunately, I just don't have access to enough
> > bandwidth or data to download them to hopefully find the date that
> > there was a change that messed things up.
> >
> > Try boot -c then disable amdgpu
> > Might help. Also try boot -s and wait. If it shuts down there too,
> > probably have the same problem. Or not. :-)
> >
> > I'm stuck at 6.6 -stable for now.
> >
> > Chris Bennett
> >
> >
> > > Thnaks.
> > >
> > > Jon
> > >
> > >
> > > xorg.conf:
> > > Section "Device"
> > > Identifier "graphicsdriver"
> > > #Driver "AMDGPU"
> > > #Option "TearFree" "true"
> > > Driver "vesa"
> > > EndSection
> > >
> > >
> > >
> > > Xorg.0.log:
> > > [124569.415] (--) checkDevMem: using aperture driver /dev/xf86
> > > [124569.425] (--) Using wscons driver on /dev/ttyC4
> > > [124569.446]
> > > X.Org X Server 1.20.5
> > > X Protocol Version 11, Revision 0
> > > [124569.446] Build Operating System: OpenBSD 6.6 amd64
> > > [124569.446] Current Operating System: OpenBSD laptop.jonjfineman.me
> > > 6.6 GENERIC.MP#3 amd64 [124569.447] Build Date: 30 July 2020
> > > 11:25:30AM [124569.447]
> > > [124569.447] Current version of pixman: 0.38.4
> > > [124569.447] Before reporting problems, check
> > > http://wiki.x.org to make sure that you have the latest version.
> > > [124569.447] Markers: (--) probed, (**) from config file, (==)
> > > default setting, (++) from command line, (!!) notice, (II)
> > > informational, (WW) warning, (EE) error, (NI) not implemented, (??)
> > > unknown. [124569.447] (==) Log file: "/var/log/Xorg.0.log", Time:
> > > Sun Aug 9 05:48:55 2020 [124569.447] (==) Using config file:
> > > "/etc/X11/xorg.conf" [124569.447] (==) Using system config directory
> > > "/usr/X11R6/share/X11/xorg.conf.d" [124569.447] (==) No Layout
> > > section. Using the first Screen section. [124569.447] (==) No
> > > screen section available. Using defaults. [124569.447] (**)
> > > |-->Screen "Default Screen Section" (0) [124569.447] (**) |
> > > |-->Monitor "" [124569.448] (==) No device
> > > specified for screen "Default Screen Section". Using the first
> > > device section listed. [124569.448] (**) | |-->Device
> > > "graphicsdriver" [124569.448] (==) No monitor specified for screen
> > > "Default Screen Section". Using a default monitor configuration.
> > > [124569.448] (==) Automatically adding devices
> > > [124569.448] (==) Automatically enabling devices
> > > [124569.448] (==) Not automatically adding GPU devices
> > > [124569.448] (==) Max clients allowed: 256, resource mask: 0x1f
> > > [124569.448] (==) FontPath set to:
> > > /usr/X11R6/lib/X11/fonts/misc/,
> > > /usr/X11R6/lib/X11/fonts/TTF/,
> > > /usr/X11R6/lib/X11/fonts/OTF/,
> > > /usr/X11R6/lib/X11/fonts/Type1/,
> > > /usr/X11R6/lib/X11/fonts/100dpi/,
> > >
Re: X11 VESA Driver Config Question
Oh, I'm "glad" someone else is having the same problem. (Sorry) I had gotten to the point of assuming a hardware problem. Being able to rule that out is nice. At least there is hope in getting a fix. I'm really not in a position to buy another one. $$ missing. If any developer could get me a replacement, I will gladly send mine. This is a pretty crappy laptop, so anything used and not very powerful fits my needs. I'm doing my porting work off of my servers anyway. Firefox, vim and lightweight use of something like gimp occasionally are all I need == Thinking about it, my servers are i386 running amd64. Would that be OK to run a build off of and install on the laptop? I have one that I could interrupt that way. == Chris Bennett
Re: explicit_bzero vs. alternatives
Am 11.08.20 um 02:52 schrieb Theo de Raadt: > > But no, WG14 are the lords and masters in the high castle, and now 6 > years after the ship sailed something Must Be Done, it must look like > They Solved The Problem, and so they'll create an incompatible API. > > Will they be heroes? No, not really. Changing the name is villainous. > The purpose of WG14 is to codify existing practise, not to invent (see N2086 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm, 8. and 13.). WG14 has reserved some identifiers for future extensions of the standard. E.g. those starting with mem_. Naturally, others then choose identifiers that do not conflict with this, such as explicit_bzero. But if that name is then used in the standard unchanged, it would mean that future extensions only use exactly those identifiers not reserved for future extensions. Philipp
Re: explicit_bzero vs. alternatives
On Tue, Aug 11, 2020 at 08:13:24AM +0200, Philipp Klaus Krause wrote: > Am 11.08.20 um 02:52 schrieb Theo de Raadt: > > > > But no, WG14 are the lords and masters in the high castle, and now 6 > > years after the ship sailed something Must Be Done, it must look like > > They Solved The Problem, and so they'll create an incompatible API. > > > > Will they be heroes? No, not really. Changing the name is villainous. > > > > The purpose of WG14 is to codify existing practise, not to invent (see > N2086 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm, 8. and > 13.). > > WG14 has reserved some identifiers for future extensions of the > standard. E.g. those starting with mem_. Naturally, others then choose > identifiers that do not conflict with this, such as explicit_bzero. But > if that name is then used in the standard unchanged, it would mean that > future extensions only use exactly those identifiers not reserved for > future extensions. > > Philipp But if we would use reserved identifiers, we would be castigated for that. Don't you see your process does not work? -Otto
Re: explicit_bzero vs. alternatives
>> >> WG14 has reserved some identifiers for future extensions of the >> standard. E.g. those starting with mem_. Naturally, others then choose >> identifiers that do not conflict with this, such as explicit_bzero. But >> if that name is then used in the standard unchanged, it would mean that >> future extensions only use exactly those identifiers not reserved for >> future extensions. >> >> Philipp > > But if we would use reserved identifiers, we would be castigated for that. > > Don't you see your process does not work? > > -Otto > This is not the only aspect broken about reserved identifiers. C2X will introduce thousands of new functions (nearly all of them for floating-point), many with names not previously reserved. C++ has their namespaces, but there is no such solution for C. I don't know how to solve this problem, and I don't think there will be a solution anytime soon. In the end, I wouldn't be surprised, if WG14 just goes with one of the existing names, not caring about reserved identifiers. But introducing a new name, from the reserved identifiers, for functionality, for which implementation experience already exists using a non-reserved name, still looks like a legitimate appoach to me. Philipp
Re: explicit_bzero vs. alternatives
On Tue, Aug 11, 2020 at 08:20:32AM +0200, Otto Moerbeek wrote: > On Tue, Aug 11, 2020 at 08:13:24AM +0200, Philipp Klaus Krause wrote: > > > Am 11.08.20 um 02:52 schrieb Theo de Raadt: > > > > > > But no, WG14 are the lords and masters in the high castle, and now 6 > > > years after the ship sailed something Must Be Done, it must look like > > > They Solved The Problem, and so they'll create an incompatible API. > > > > > > Will they be heroes? No, not really. Changing the name is villainous. > > > > > > > The purpose of WG14 is to codify existing practise, not to invent (see > > N2086 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm, 8. and > > 13.). > > > > WG14 has reserved some identifiers for future extensions of the > > standard. E.g. those starting with mem_. Naturally, others then choose > > identifiers that do not conflict with this, such as explicit_bzero. But > > if that name is then used in the standard unchanged, it would mean that > > future extensions only use exactly those identifiers not reserved for > > future extensions. > > > > Philipp > > But if we would use reserved identifiers, we would be castigated for that. > > Don't you see your process does not work? > > -Otto > Let me elaborate. IMO, if the WG refuses to include a common function user in various platforms into the standard and instead insist on naming it differently it just creates confusion and work and thus bugs. In that, it hinders progress instead of enabling it. -Otto
Re: static IPv6 setup is not working stable
Hi Demi, have done: ndp -s fe80::1%vio0 00:00:5e:00:02:02 which results in a nearly permanent setup: Neighbor Linklayer Address Netif ExpireS Flags 2a03:4000:24:82f:: d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::1 d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::4500 d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::5353 d6:16:7b:a0:ce:63vio0 permanent R l 2a03:4000:24:82f::8022 d6:16:7b:a0:ce:63vio0 permanent R l fd91:24d4:fa4c:379d::1 d6:16:7b:a0:ce:64vio1 permanent R l fe80::1%vio0 00:00:5e:00:02:02vio0 23h59m54s S R fe80::22d8:b00:89ee:ff4%vio0 2c:6b:f5:a0:77:c0vio0 23h57m43s S R fe80::22d8:b00:89fa:424c%vio010:0e:7e:26:f1:c0vio0 23h44m43s S R fe80::d416:7bff:fea0:ce63%vio0 d6:16:7b:a0:ce:63vio0 permanent R l fe80::d416:7bff:fea0:ce64%vio1 d6:16:7b:a0:ce:64vio1 permanent R l So the gateway is now “ticking” around the 23h59m. It doesn’t run stable at all. Ping6 from the outside: 16 bytes from 2a03:4000:24:82f::4500, icmp_seq=16 hlim=58 time=680.134 ms 16 bytes from 2a03:4000:24:82f::4500, icmp_seq=17 hlim=58 time=81.254 ms Aug 10 17:12:58.718515 rule 5._2.1/(match) pass in on vio0: 2001:470:7309:8400:8258:5a7c:fe68:afdd > 2a03:4000:24:82f::4500: icmp6: echo request [flowlabel 0xec744] Aug 10 17:12:59.546185 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff00:bca4: [|icmp6] [class 0xc0] Aug 10 17:12:59.547423 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff4a:3f62: [|icmp6] [class 0xc0] Aug 10 17:12:59.550876 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff06:ad8f: [|icmp6] [class 0xc0] Aug 10 17:12:59.554148 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff73:d955: [|icmp6] [class 0xc0] Aug 10 17:12:59.642650 rule 3.ND.5/(match) pass in on vio0: fe80::22d8:b00:89ee:ff4 > ff02::1:ff00:2: [|icmp6] [class 0xc0] So it works like in the past, that a lot off packages goes lost first, than it works for a time and than it goes off again. Kind regards, Kay-Uwe > The best option I know of is to add a static, permanent NDP entry > with ndp(8) entry before bringing up the interface. This works even > if the peer does not respond to NDP at all. > > Sincerely, > > Demi signature.asc Description: Message signed with OpenPGP using GPGMail
laptop cpu high temperature while idle
Fresh install of OpenBSD/6.7/amd64/install67.fs on Lenovo 3000 G530 laptop, 2008 manufacture year. Straight from the start, just after log in: CPU: 100% idle load averages: 0.04, 0.06, 0.04 $ sysctl hw.sensors | grep temp hw.sensors.cpu0.temp0=95.00 degC hw.sensors.acpitz0.temp0=79.00 degC (zone temperature) and growed by 1 degC in 3 minutes of inactivity. Found: https://www.reddit.com/r/openbsd/comments/gmmh98/has_high_cpuheat_issue_been_fixed_in_67/ which has also this link: https://old.reddit.com/r/openbsd/comments/e6qf3m/66_t420_heat/ but: 1. no solution there; 2. there temperature average is higher by a few degC, or rises inadequately under some particular load, mine - is constantly inadequate under no load. Also, it takes several seconds for xterm to redraw itself from top to bottom on my 1280x800 display. Is it because of NVIDIA graphics? Has it something to do with high temperature? I have not tried OpenBSD/6.5 mentioned in the above links - I am a new-comer. I have not syspatch'ed - I am afraid of keeping my machine running at a-little-below-water-boiling temperature. Anyway, both https://www.openbsd.org/errata67.html https://www.openbsd.org/plus.html seem to me to not contain temperature fixes. screenshot of hot while idle: https://i.postimg.cc/9fj29RHN/IMG-20200810-212534.jpg https://i.postimg.cc/2698nkwb/IMG-20200810-212848.jpg screenshots of dmesg: https://i.postimg.cc/sD7GCWmT/IMG-20200810-212954.jpg https://i.postimg.cc/kGRYwsxN/IMG-20200810-213019.jpg https://i.postimg.cc/zG3BXRFm/IMG-20200810-213036.jpg dmesg from Linux live usb: https://hastebin.com/raw/evokawoxuz Any hints?
Re: explicit_bzero vs. alternatives
Theo de Raadt wrote in <61139.1597087...@cvs.openbsd.org>: |Philipp Klaus Krause wrote: |> Am 10.08.20 um 17:00 schrieb Theo de Raadt: |>> Philipp Klaus Krause wrote: |>> |>>> OpenBSD has the explicit_bzero function to reliably (i.e. even if not |>>> observable in the C abstract machine) overwrite memory with zeroes. |>>> |>>> WG14 is currently considering adding similar functionality to C2X. |>> |>> Then perhaps in the interests of the public they should use the same |>> name, but I suspect they won't. |> |> The functionality (i.e. some way to reliably overwrite memory) already |> exists under different names: explicit_bzero in OpenBSD | |This one was first. If i recall correctly others had already started using volatile pointers to memset(3) before. 'Kind of strange that bcopy etc. all were thrown away, just to bring back a bzero to circumvent overoptimization of compilers. That "reliably overwrite memory" .. bugs me, i know that ship has sailed, but if the programmer calls a function then for a reason. Sorry, the topic concerns me. --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: laptop cpu high temperature while idle
o...@mailo.com wrote: > CPU: 100% idle > load averages: 0.04, 0.06, 0.04 100% idle means "100% doing nothing". This is normal for a CPU that does nothing. > $ sysctl hw.sensors | grep temp > hw.sensors.cpu0.temp0=95.00 degC > hw.sensors.acpitz0.temp0=79.00 degC (zone temperature) This seems hot for doing nothing. Does it run cooler on Linux? I also wonder if the reading is correct. Does the fan speed up further than under linux? If the CPU has 95 degrees, you should be able to feel a pretty hot airflow and hear the fan spinning high. If this is not the case, I assume the reading is not correct. Did you enable automatic frequency scaling? $ cat /etc/rc.conf.local apmd_flags=-A > Also, it takes several seconds for xterm to redraw itself > from top to bottom on my 1280x800 display. > Is it because of NVIDIA graphics? Stay away from Nvidia if possible (disable it in the BIOS if you have hybrid graphics). Nvidia cards will be driven by the vesa / framebuffer module, which is pretty slow on any hardware. > Has it something to do with high temperature? No. If the machine has never been serviced and the temperature seems to be high on any OS, then cleaning the heat sink and replacing the thermal compound may help. Best Regards, Stefan
Re: explicit_bzero vs. alternatives
Philipp Klaus Krause wrote: > In the end, I wouldn't be surprised, if WG14 just goes with one of the > existing names, not caring about reserved identifiers. There is only one existing name in common use. Even glibc chose to go with the name explicit_bzero. I notice you keep using the other names, wilfully ignoring the reality on the ground. > But introducing a new name, from the reserved identifiers, for > functionality, for which implementation experience already exists using > a non-reserved name, still looks like a legitimate appoach to me. Legitimate like pulling a sword from a rock.
Re: No xenocara for ATI Radeon HD 2400 XT
Thus said Jonathan Gray on Mon, 10 Aug 2020 23:54:54 +1000: > For now we could just skip reading a disabled bios on RV610. Thanks, that tweak seems to have gotten past the problem and now X will start: initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00). radeondrm0: 1680x1050, 32bpp wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) I wonder what the difference is between i386 and amd64... Thanks, Andy
Re: laptop cpu high temperature while idle
>> $ sysctl hw.sensors | grep temp >> hw.sensors.cpu0.temp0=95.00 degC >> hw.sensors.acpitz0.temp0=79.00 degC (zone temperature) > This seems hot for doing nothing. Does it run cooler on Linux? 1. Linux live usb, right after reboot from OpenBSD: $ sensors coretemp-isa- Adapter: ISA adapter Core 0: +79.0°C (high = +85.0°C, crit = +85.0°C) Core 1: +78.0°C (high = +85.0°C, crit = +85.0°C) acpitz-virtual-0 Adapter: Virtual device temp1:+76.0°C (crit = +119.0°C) nouveau-pci-0100 Adapter: PCI adapter GPU core: +0.90 V (min = +0.90 V, max = +1.17 V) temp1:+85.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +2.0°C) (emerg = +110.0°C, hyst = +5.0°C) 2. Linux live usb, soon after reboot from OpenBSD: $ sensors coretemp-isa- Adapter: ISA adapter Core 0: +75.0°C (high = +85.0°C, crit = +85.0°C) Core 1: +75.0°C (high = +85.0°C, crit = +85.0°C) acpitz-virtual-0 Adapter: Virtual device temp1:+73.0°C (crit = +119.0°C) nouveau-pci-0100 Adapter: PCI adapter GPU core: +0.90 V (min = +0.90 V, max = +1.17 V) temp1:+81.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +2.0°C) (emerg = +110.0°C, hyst = +5.0°C) 3. Linux live usb, idle for longer time: $ sensors coretemp-isa- Adapter: ISA adapter Core 0: +72.0°C (high = +85.0°C, crit = +85.0°C) Core 1: +72.0°C (high = +85.0°C, crit = +85.0°C) acpitz-virtual-0 Adapter: Virtual device temp1:+70.0°C (crit = +119.0°C) nouveau-pci-0100 Adapter: PCI adapter GPU core: +0.90 V (min = +0.90 V, max = +1.17 V) temp1:+78.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +2.0°C) (emerg = +110.0°C, hyst = +5.0°C) 4. Linux live usb, idle for long time, outdoors: $ sensors coretemp-isa- Adapter: ISA adapter Core 0: +63.0°C (high = +85.0°C, crit = +85.0°C) Core 1: +64.0°C (high = +85.0°C, crit = +85.0°C) acpitz-virtual-0 Adapter: Virtual device temp1:+62.0°C (crit = +119.0°C) nouveau-pci-0100 Adapter: PCI adapter GPU core: +0.90 V (min = +0.90 V, max = +1.17 V) temp1:+69.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +2.0°C) (emerg = +110.0°C, hyst = +5.0°C) > I also wonder if the reading is correct. Does the fan speed up further > than under linux? If the CPU has 95 degrees, you should be able to feel > a pretty hot airflow and hear the fan spinning high. I can not definitely confirm that OpenBSD fan airflow is hotter than Linux one, maybe yes, but it is within the margin of error of my sense of touch and I am not equipped with a meter. In both cases airflow is hot. I also can not definitely confirm that fan speed is further. I have been using this laptop for months with Linux and fan behavior seems indistinguishable, whatever load is. I suppose, it is always at its max. > Did you enable automatic frequency scaling? I had enabled apmd but had not set the -A flag. After your reply I added -A and rebooted, result: 91 degC - log in temperature 87 degC - after a while, and not dropping screenshot: https://i.postimg.cc/rpVF1QSx/IMG-20200811-163108.jpg >> Also, it takes several seconds for xterm to redraw itself >> from top to bottom on my 1280x800 display. >> Is it because of NVIDIA graphics? > Stay away from Nvidia if possible (disable it in the BIOS if you have > hybrid graphics). Nvidia cards will be driven by the vesa / framebuffer > module, which is pretty slow on any hardware. Only discrete NVIDIA is installed, no hybrid-graphics, so if the reading is correct, this is another reason why I am unfortunate to be incapable of running an OpenBSD desktop on this laptop... > If the machine has never been serviced and the temperature seems to be > high on any OS, then cleaning the heat sink and replacing the thermal > compound may help. It certainly has to be done. Thank you, Stefan. Current summary: OpenBSD is still too hot - 87 degC cpu temperature while idle
