Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Tue, Sep 28, 2021 at 10:16:23PM -0600, Theo de Raadt wrote: > Your dmesg lacks tpm0. You probably disabled it in the BIOS: > > "STM7304" at acpi0 not configured > > If you re-enable TPM uit in the BIOS, and try a snapshot (or upcoming > 7.0) there is a recent fix which may help. It is a potential reason for > the interrupts... I have re-enabled TPM in the BIOS. Alas, a freshly installed snapshot (dmesg below) still shows the same problem (1 core at 100% CPU usage running what 'top -S -i -s1' says is 'acpi0') after doing a suspend/resume. Tomorrow I will try Mike Larkin's suggestion of an ACPI_DEBUG kernel and zzz/un-zzz from the text console. --- begin snapshot dmesg --- OpenBSD 7.0 (GENERIC.MP) #231: Mon Sep 27 17:23:17 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16755720192 (15979MB) avail mem = 16231878656 (15479MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa86db000 (62 entries) bios0: vendor LENOVO version "N27ET43W (1.29 )" date 08/13/2021 bios0: LENOVO 20L9001GUS acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1793.88 MHz, 06-8e-0a 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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 24MHz 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-8650U CPU @ 1.90GHz, 1794.44 MHz, 06-8e-0a 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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a cpu2: 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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a cpu3: 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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus -1 (RP03) acpiprt4 at acpi0: bus -1 (RP04)
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote: > the term "runaway ACPI" is not the best. What is probably happening > is a stuck interrupt. > > We continue to fight these. Some of them are BIOS bugs, some are > undocumented behaviours, sometimes AML parse errors in setting things > up, and potentially a few are due to incorrect resume sequencing. > The suspend/resume specification is weak, and getting even weaker as > time goes by and newer machines come out which are poorly tested by > even the mainstream OS vendors. > > Jonathan Thornburg wrote: > > > After more experimentation, I find that the runaway ACPI process occurs > > every time I suspend/resume (Fn-backspace). (The system resumes fine > > apart from the runaway ACPI process.) > > > > Is there any to kill or reset the kernel ACPI process short of rebooting? > > /ps/ doen't see it, and /pkill/ (even /pkill -9/) has no effect. > > No you cannot kill kernel threads... > > > I will try compiling a custom kernel with ACPITHINKPAD_DEBUG defined > > in /usr/src/sys/dev/acpi/acpithinkpad.c and see if that prints anything > > interesting. Are there any other particularly useful debugging things > > I should explore to help track down the problem? > > There are a few people who have experience with this. Maybe one of > them will mail you privately. > If you build an ACPI_DEBUG kernel and zzz/un-zzz from the text console (not X), you might see what GPE is stuck. it will probably be spewing tons of debug output but maybe you can see which GPE it is. -ml
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
Hi Theo :) Ok sure, I will put on my cape-of-courage and start reading the source.. I may be some time! On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt wrote: > We tend to keep our driver manual pages without detailed promises. > They do ethernet, they do it best effort, etc. > > What you want to know can be found by reading the source, or the > commit logs. Since this is a locally written driver, the code is > surprisingly approachable. > > Andrew Lemin wrote: > > > Hi. I hope everyone is well and having a great day :) > > > > Just a quick question about the mcx (Mellanox 5th generation Ethernet > > device) drivers > > https://man.openbsd.org/mcx.4 > > > > The man page says nothing more than it supports; > > ConnectX-4 Lx EN > > ConnectX-4 EN > > ConnectX-5 EN > > ConnectX-6 EN > > > > I am looking for some clarity on what features and performance > > characteristics mcx boasts? > > > > For example are the following basic hardware features supported by this > > driver? > > IPv4 receive IP/TCP/UDP checksum offload > > IPv4 transmit TCP/UDP checksum offload > > VLAN tag insertion and stripping > > interrupt coalescing > > > > And what other features does it support? > > > > I also came across a comment in some forum a while back (so high quality > > information ) that mentioned Mellanox drivers in OpenBSD are SMP safe > and > > so not giant-locked. Is this true? > > > > Thanks, Andy, >
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
I see this question died on its arse! :) This is still an issue for outbound load-balancing over multiple internet links. PF's 'sticky-address' parameter only works on source IPs (because it was originally designed for use when hosting your own server pools - inbound load balancing). I.e. There is no way to configure 'sticky-address' to consider destination IPs for outbound load balancing, so all subsequent outbound connections to the same target IP originate from the same internet connection. The reason why this is desirable is because an increasing number of websites use single sign on mechanisms (quite a few different architectures expose the issue described here). After a users outbound connection is initially randomly load balanced onto an internet connection, their browser is redirected into opening multiple additional sockets towards the website's load balancers / cloud gateways, which redirect the connections to different internal servers for different parts of the site/page, and the SSO authentication/cookies passed on the additional sockets must to originate from the same IP as the original socket. As a result outbound load-balancing does not work for these sites. The ideal functionality would be for 'sticky-address' to consider both source IP and destination IP after initially being load balanced by round-robin or random. Thanks again, Andy. On Sat, Apr 3, 2021 at 12:40 PM Andy Lemin wrote: > Hi smart people :) > > The current implementation of ‘sticky-address‘ relates only to a sticky > source IP. > https://www.openbsd.org/faq/pf/pools.html > > This is used for inbound server load balancing, by ensuring that all > socket connections from the same client/user/IP on the internet goes to the > same server on your local server pool. > > This works great for ensuring simplified memory management of session > artefacts on the application being hosted (the servers do not have to > synchronise the users session data as extra sockets from that user will > always connect to the same local server) > > However sticky-address does not have an equivalent for sticky destination > IPs. For example when doing outbound load balancing over multiple ISP > links, every single socket is load balanced randomly. This causes many > websites to break (especially cookie login and single-sign-on style > enterprise services), as the first outbound socket will originate randomly > from one of the local ISP IPs, and the users login session/SSO (on the > server side) will belong to that first random IP. > > When the user then browses to or uses another part of that same website > which requires additional sockets, the additional sockets will pass the SSO > credentials from the first socket, but the extra socket connection will > again be randomly load-balanced, and so the remote server will reject the > connection as it is originating from the wrong source IP etc. > > Therefore can I please propose a “sticky-address for destination IPs” as > an analogue to the existing sticky-address for source IPs? > > This is now such a problem that we have to use sticky-address even on > outbound load-balancing connections, which causes internal user1 to always > use the same ISP for _everthing_ etc. While this does stop the breakage, it > does not result in evenly distributed balancing of traffic, as users are > locked to one single transit, for all their web browsing for the rest of > the day after being randomly balanced once first-thing in the morning, > rather than all users balancing over all transits throughout the day. > > Another pain; using the current source-ip sticky-address for outbound > balancing, makes it hard to drain transits for maintenance. For example > without source sticky-address balancing, you can just remove the transit > from the Pf rule, and after some time, all traffic will eventually move > over to the other transits, allowing the first to be shut down for whatever > needs. But with the current source-ip sticky-address, that first transit > will take months to drain in a real-world situations.. > > lastly just as a nice-to-have, how feasible would a deterministic load > balancing algorithm be? So that balancing selection is done based on the > “least utilised” path? > > Thanks for your time and consideration, > Kindest regards Andy > > > > Sent from a teeny tiny keyboard, so please excuse typos. >
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
> bios0: vendor LENOVO version "N27ET43W (1.29 )" date 08/13/2021 > bios0: LENOVO 20L9001GUS > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 On the other hand, your BIOS is very new. So new that it has S0. These days Microsoft is only testing S0. Lenovo and some other vendors are re-adding S3, because S0 suspend is a festering pile of crap which only works in Windows, well barely, on a good day maybe. But the S3 re-added is still very new BIOS (SMI?) emulation and it has glitches. It will take some time to mature. You have a tremendous amount of wakeup devices which could be implicated in this: acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] Your dmesg lacks tpm0. You probably disabled it in the BIOS: "STM7304" at acpi0 not configured If you re-enable TPM uit in the BIOS, and try a snapshot (or upcoming 7.0) there is a recent fix which may help. It is a potential reason for the interrupts...
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
BTW, BIOS update has fixed interrupts issues like this in a surprising number of cases. No promises, tho. Jonathan Thornburg wrote: > After more experimentation, I find that the runaway ACPI process occurs > every time I suspend/resume (Fn-backspace). (The system resumes fine > apart from the runaway ACPI process.) > > Is there any to kill or reset the kernel ACPI process short of rebooting? > /ps/ doen't see it, and /pkill/ (even /pkill -9/) has no effect. > > I will try compiling a custom kernel with ACPITHINKPAD_DEBUG defined > in /usr/src/sys/dev/acpi/acpithinkpad.c and see if that prints anything > interesting. Are there any other particularly useful debugging things > I should explore to help track down the problem? > > -- > -- "Jonathan Thornburg [remove color- to reply]" >on the west coast of Canada, eh? >"There was of course no way of knowing whether you were being watched > at any given moment. How often, or on what system, the Thought Police > plugged in on any individual wire was guesswork. It was even conceivable > that they watched everybody all the time." -- George Orwell, "1984" >
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
the term "runaway ACPI" is not the best. What is probably happening is a stuck interrupt. We continue to fight these. Some of them are BIOS bugs, some are undocumented behaviours, sometimes AML parse errors in setting things up, and potentially a few are due to incorrect resume sequencing. The suspend/resume specification is weak, and getting even weaker as time goes by and newer machines come out which are poorly tested by even the mainstream OS vendors. Jonathan Thornburg wrote: > After more experimentation, I find that the runaway ACPI process occurs > every time I suspend/resume (Fn-backspace). (The system resumes fine > apart from the runaway ACPI process.) > > Is there any to kill or reset the kernel ACPI process short of rebooting? > /ps/ doen't see it, and /pkill/ (even /pkill -9/) has no effect. No you cannot kill kernel threads... > I will try compiling a custom kernel with ACPITHINKPAD_DEBUG defined > in /usr/src/sys/dev/acpi/acpithinkpad.c and see if that prints anything > interesting. Are there any other particularly useful debugging things > I should explore to help track down the problem? There are a few people who have experience with this. Maybe one of them will mail you privately.
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
After more experimentation, I find that the runaway ACPI process occurs every time I suspend/resume (Fn-backspace). (The system resumes fine apart from the runaway ACPI process.) Is there any to kill or reset the kernel ACPI process short of rebooting? /ps/ doen't see it, and /pkill/ (even /pkill -9/) has no effect. I will try compiling a custom kernel with ACPITHINKPAD_DEBUG defined in /usr/src/sys/dev/acpi/acpithinkpad.c and see if that prints anything interesting. Are there any other particularly useful debugging things I should explore to help track down the problem? -- -- "Jonathan Thornburg [remove color- to reply]" on the west coast of Canada, eh? "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
We tend to keep our driver manual pages without detailed promises. They do ethernet, they do it best effort, etc. What you want to know can be found by reading the source, or the commit logs. Since this is a locally written driver, the code is surprisingly approachable. Andrew Lemin wrote: > Hi. I hope everyone is well and having a great day :) > > Just a quick question about the mcx (Mellanox 5th generation Ethernet > device) drivers > https://man.openbsd.org/mcx.4 > > The man page says nothing more than it supports; > ConnectX-4 Lx EN > ConnectX-4 EN > ConnectX-5 EN > ConnectX-6 EN > > I am looking for some clarity on what features and performance > characteristics mcx boasts? > > For example are the following basic hardware features supported by this > driver? > IPv4 receive IP/TCP/UDP checksum offload > IPv4 transmit TCP/UDP checksum offload > VLAN tag insertion and stripping > interrupt coalescing > > And what other features does it support? > > I also came across a comment in some forum a while back (so high quality > information ) that mentioned Mellanox drivers in OpenBSD are SMP safe and > so not giant-locked. Is this true? > > Thanks, Andy,
Mellanox driver support details https://man.openbsd.org/mcx.4
Hi. I hope everyone is well and having a great day :) Just a quick question about the mcx (Mellanox 5th generation Ethernet device) drivers https://man.openbsd.org/mcx.4 The man page says nothing more than it supports; ConnectX-4 Lx EN ConnectX-4 EN ConnectX-5 EN ConnectX-6 EN I am looking for some clarity on what features and performance characteristics mcx boasts? For example are the following basic hardware features supported by this driver? IPv4 receive IP/TCP/UDP checksum offload IPv4 transmit TCP/UDP checksum offload VLAN tag insertion and stripping interrupt coalescing And what other features does it support? I also came across a comment in some forum a while back (so high quality information ) that mentioned Mellanox drivers in OpenBSD are SMP safe and so not giant-locked. Is this true? Thanks, Andy,
Re: PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels
Hi. Sorry for extremely slow reply! Did you add the return routes for your internal subnets into each of the per-tun rdomains? To test your tunnels are setup correctly; Once you have the external interface in rdomain 0, and each VPN instance's tun interface is bound to different rdomains etc, you can test that your tunnel setup is working within the rdomain with "ping -V1 1.1.1.1" (to originate a ping within rdomain 1 for example). If the ping works, but gets lost when routing through the interface pair ( https://man.openbsd.org/pair), then check the routing table in rdomain 1 with "route -T1 show". Your tunnel will be the default gateway within that rdomain, but you will still need routes in the rdomain to get the return packets back to your internal networks. For this in my /etc/hostname.pair1 interface (pair interface that sits in rdomain 1), I add the line "!/sbin/route -T1 add 172.16.0.0/12 192.168.251.2" (where 192.168.251.2 is the IP for the peer-pair interface that sits in my internal rdomain 1). On Wed, May 8, 2019 at 12:09 AM mike42 wrote: > Trying to replicate same setup with pairs and different rdomains for each > tun > and also external interface, after a packet goes through pair interfaces > it's just disapears. > > Any ideas? > > routing in rdomain is set like: > > route -T add default tun > route -T add > > > > > > -- > Sent from: > http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html > >
Re: relayd, rsae_send_imsg: privenc poll timeout
On Thu, Sep 16, 2021, at 6:43 PM, Allan Streib wrote: > On Tue, Sep 14, 2021, at 5:09 PM, Allan Streib wrote: > > Seen a few of these in my logs (OpenBSD 6.9 release amd64) > > > > Sep 14 02:12:05 relayd[78491]: rsae_send_imsg: privenc poll > > timeout, keyop #946 > > Sep 14 02:12:06 relayd[78491]: relay_dispatch_ca: privenc result > > after timeout > > > > The number after "keyop" varies. > > Seeing a few more of these, the system is lightly loaded but it's a hosted > KVM "slice" > so perhaps the host system is oversubscribed? Just to close loop, hosting provider found that host machine was overheating. Moved VM to another host machine and have not seen any repeat of this problem. Allan
Re: Dell PowerEdge 730xd
On Mon, Sep 27, 2021 at 05:30:01PM +0200, Manuel Giraud wrote: > Hi, > > Does anyone use one of those? I can reliably freeze them with some I/O > load with rsync for example. I don't have much more to say. Here is the > dmesg: Does this IO load involve either of the SSDs you have set up as physical disks, or just the logical volumes? mfii(4) has problems with physical disks. > mfii0 at pci2 dev 0 function 0 "Symbios Logic MegaRAID SAS3008" rev 0x02: msi > mfii0: "PERC H330 Mini", firmware 25.5.9.0001 > scsibus1 at mfii0: 32 targets > sd0 at scsibus1 targ 0 lun 0: > naa.6847beb0d516f200280aad2411ac7def > sd0: 17167872MB, 512 bytes/sector, 35159801856 sectors > sd1 at scsibus1 targ 1 lun 0: > naa.6847beb0d516f2001fb4d99b9b6286a2 > sd1: 22890496MB, 512 bytes/sector, 46879735808 sectors these are the logical volumes > scsibus2 at mfii0: 256 targets > sd2 at scsibus2 targ 12 lun 0: > naa.55cd2e404c30d033 > sd2: 190782MB, 512 bytes/sector, 390721968 sectors, thin > sd3 at scsibus2 targ 13 lun 0: > naa.55cd2e404c30d78f > sd3: 190782MB, 512 bytes/sector, 390721968 sectors, thin and these are the physical disks.
Re: Raspberry Pi 4 Model B
On Mon, Sep 27, 2021 at 10:55:16AM -, Stuart Henderson wrote: > On 2021-09-26, Joseph Olatt wrote: > > Hi Matheus and beebeet...@posteo.de, > > > > I have OpenBSD 6.9 successfully running on multiple Raspberry Pi 3Bs > > without any issues. The one that is having issues is a 4B. I am > > following the instructions at: > > > > https://ftp.openbsd.org/pub/OpenBSD/6.9/arm64/INSTALL.arm64 > > > > and when I try to boot up, I get: > > Try a snapshot instead, the newer U-Boot version might work better. > (There have been various hardware revisions of the Pi 4 model B). Thank you for the suggestion. I tried the following snapshot: https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot70.img Build date: 27-Sep-2021 20:10 Size: 45088768 Didn't have much luck. The install process rebooted after the following error: bwfm0: failed loadfirmware of file brcmfmac43455-sdio.raspberrypi,4-model-b.bin panic: do_el0_error Wonder if the following error in the beginning (full transcript of install process listed below): libfdt fdt_check_header(): FDT_ERR_BADMAGIC has anything to do with my woes... Next, I'll try the pftf UEFI firmware mentioned in INSTALL.arm64, per your suggestion, as soon as I find some spare time. /* Full transcript of install */ Connected to /dev/cuaU0 (speed 115200) U-Boot 2021.07 (Aug 12 2021 - 02:45:29 -0600) DRAM: 3.9 GiB RPI 4 Model B (0xc03114) MMC: mmcnr@7e30: 1, emmc2@7e34: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: serial Err: serial Net: eth0: ethernet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! : -110 Scanning disk mm...@7e30.blk... Disk mm...@7e30.blk not ready Scanning disk em...@7e34.blk... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 170694 bytes read in 33 ms (4.9 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi disks: sd0* >> OpenBSD/arm64 BOOTAA64 1.6 boot> cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 2574016+699492+13009456+629216 [216000+109+596472+233168]=0x14014c8 type 0x0 pa 0x0 va 0x0 pages 0x1 attr 0x8 type 0x7 pa 0x1000 va 0x1000 pages 0x1ff attr 0x8 type 0x2 pa 0x20 va 0x20 pages 0x4000 attr 0x8 type 0x7 pa 0x420 va 0x420 pages 0x3cf0 attr 0x8 type 0x9 pa 0x7ef va 0x7ef pages 0x20 attr 0x8 type 0x7 pa 0x7f1 va 0x7f1 pages 0x31ef0 attr 0x8 type 0x4 pa 0x39e0 va 0x39e0 pages 0x1 attr 0x8 type 0x7 pa 0x39e01000 va 0x39e01000 pages 0x1 attr 0x8 type 0x2 pa 0x39e02000 va 0x39e02000 pages 0x100 attr 0x8 type 0x1 pa 0x39f02000 va 0x39f02000 pages 0x2a attr 0x8 type 0x0 pa 0x39f2c000 va 0x39f2c000 pages 0x7 attr 0x8 type 0x4 pa 0x39f33000 va 0x39f33000 pages 0x1 attr 0x8 type 0x6 pa 0x39f34000 va 0x3d35274000 pages 0x1 attr 0x8008 type 0x4 pa 0x39f35000 va 0x39f35000 pages 0x2 attr 0x8 type 0x0 pa 0x39f37000 va 0x39f37000 pages 0x1 attr 0x8 type 0x6 pa 0x39f38000 va 0x3d35278000 pages 0x3 attr 0x8008 type 0x4 pa 0x39f3b000 va 0x39f3b000 pages 0x1 attr 0x8 type 0x6 pa 0x39f3c000 va 0x3d3527c000 pages 0x4 attr 0x8008 type 0x0 pa 0x39f4 va 0x39f4 pages 0x1 attr 0x8 type 0x4 pa 0x39f41000 va 0x39f41000 pages 0x1 attr 0x8 type 0x0 pa 0x39f42000 va 0x39f42000 pages 0x1 attr 0x8 type 0x4 pa 0x39f43000 va 0x39f43000 pages 0x2 attr 0x8 type 0x0 pa 0x39f45000 va 0x39f45000 pages 0x1 attr 0x8 type 0x4 pa 0x39f46000 va 0x39f46000 pages 0x2 attr 0x8 type 0x2 pa 0x39f48000 va 0x39f48000 pages 0x1408 attr 0x8 type 0x5 pa 0x3b35 va 0x3d3669 pages 0x10 attr 0x8008 type 0x2 pa 0x3b36 va 0x3b36 pages 0xa0 attr 0x8 type 0x0 pa 0x3ef5c000 va 0x3ef5c000 pages 0x1 attr 0x8 type 0x4 pa 0x4000 va 0x4000 pages 0xbc000 attr 0x8 type 0xb pa 0xfe10 va 0x3d366a pages 0x1 attr 0x8000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2021 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.0 (RAMDISK) #1249: Mon Sep 27 20:10:08 MDT 2021 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK real mem = 4124962816 (3933MB) avail mem = 3961278464 (3777MB) random:
Re: Raspberry Pi 4 Model B
On 2021-09-28, Peter J. Philipp wrote: > On Tue, Sep 28, 2021 at 10:04:25AM -0700, Joseph Olatt wrote: >> I tried the following snapshot: >> >> https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot70.img >> >> Build date: 27-Sep-2021 20:10 >> Size: 45088768 >> >> Didn't have much luck. The install process rebooted after the following >> error: >> >> bwfm0: failed loadfirmware of file >> brcmfmac43455-sdio.raspberrypi,4-model-b.bin >> panic: do_el0_error > > What happens when you boot with -c and 'disable bwfm' then exit? Is that not > an option anymore? I am pretty sure the do_el0_error is unrelated to the loadfirmware() failing (which is just because the firmware for the device isn't installed yet).
Re: Raspberry Pi 4 Model B
On Tue, Sep 28, 2021 at 10:04:25AM -0700, Joseph Olatt wrote: > I tried the following snapshot: > > https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot70.img > > Build date: 27-Sep-2021 20:10 > Size: 45088768 > > Didn't have much luck. The install process rebooted after the following > error: > > bwfm0: failed loadfirmware of file > brcmfmac43455-sdio.raspberrypi,4-model-b.bin > panic: do_el0_error What happens when you boot with -c and 'disable bwfm' then exit? Is that not an option anymore? Best Regards, -peter PS: look lower at boot line below > Wonder if the following error in the beginning (full transcript of > install process listed below): > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > has anything to do with my woes... > > Next, I'll try the pftf UEFI firmware mentioned in INSTALL.arm64, per > your suggestion, as soon as I find some spare time. > > > /* Full transcript of install */ > Connected to /dev/cuaU0 (speed 115200) > > > U-Boot 2021.07 (Aug 12 2021 - 02:45:29 -0600) > > DRAM: 3.9 GiB > RPI 4 Model B (0xc03114) > MMC: mmcnr@7e30: 1, emmc2@7e34: 0 > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > In:serial > Out: serial > Err: serial > Net: eth0: ethernet@7d58 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... 2 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Card did not respond to voltage select! : -110 > Scanning disk mm...@7e30.blk... > Disk mm...@7e30.blk not ready > Scanning disk em...@7e34.blk... > ** Unrecognized filesystem type ** > Found 3 disks > No EFI system partition > BootOrder not defined > EFI boot manager: Cannot load any image > Found EFI removable media binary efi/boot/bootaa64.efi > 170694 bytes read in 33 ms (4.9 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Booting /efi\boot\bootaa64.efi > disks: sd0* > >> OpenBSD/arm64 BOOTAA64 1.6 > boot> ^ right here type -c or 'boot -c' > cannot open sd0a:/etc/random.seed: No such file or directory > booting sd0a:/bsd: 2574016+699492+13009456+629216 > [216000+109+596472+233168]=0x14014c8 > type 0x0 pa 0x0 va 0x0 pages 0x1 attr 0x8 > type 0x7 pa 0x1000 va 0x1000 pages 0x1ff attr 0x8 > type 0x2 pa 0x20 va 0x20 pages 0x4000 attr 0x8 > type 0x7 pa 0x420 va 0x420 pages 0x3cf0 attr 0x8 > type 0x9 pa 0x7ef va 0x7ef pages 0x20 attr 0x8 > type 0x7 pa 0x7f1 va 0x7f1 pages 0x31ef0 attr 0x8 > type 0x4 pa 0x39e0 va 0x39e0 pages 0x1 attr 0x8 > type 0x7 pa 0x39e01000 va 0x39e01000 pages 0x1 attr 0x8 > type 0x2 pa 0x39e02000 va 0x39e02000 pages 0x100 attr 0x8 > type 0x1 pa 0x39f02000 va 0x39f02000 pages 0x2a attr 0x8 > type 0x0 pa 0x39f2c000 va 0x39f2c000 pages 0x7 attr 0x8 > type 0x4 pa 0x39f33000 va 0x39f33000 pages 0x1 attr 0x8 > type 0x6 pa 0x39f34000 va 0x3d35274000 pages 0x1 attr 0x8008 > type 0x4 pa 0x39f35000 va 0x39f35000 pages 0x2 attr 0x8 > type 0x0 pa 0x39f37000 va 0x39f37000 pages 0x1 attr 0x8 > type 0x6 pa 0x39f38000 va 0x3d35278000 pages 0x3 attr 0x8008 > type 0x4 pa 0x39f3b000 va 0x39f3b000 pages 0x1 attr 0x8 > type 0x6 pa 0x39f3c000 va 0x3d3527c000 pages 0x4 attr 0x8008 > type 0x0 pa 0x39f4 va 0x39f4 pages 0x1 attr 0x8 > type 0x4 pa 0x39f41000 va 0x39f41000 pages 0x1 attr 0x8 > type 0x0 pa 0x39f42000 va 0x39f42000 pages 0x1 attr 0x8 > type 0x4 pa 0x39f43000 va 0x39f43000 pages 0x2 attr 0x8 > type 0x0 pa 0x39f45000 va 0x39f45000 pages 0x1 attr 0x8 > type 0x4 pa 0x39f46000 va 0x39f46000 pages 0x2 attr 0x8 > type 0x2 pa 0x39f48000 va 0x39f48000 pages 0x1408 attr 0x8 > type 0x5 pa 0x3b35 va 0x3d3669 pages 0x10 attr 0x8008 > type 0x2 pa 0x3b36 va 0x3b36 pages 0xa0 attr 0x8 > type 0x0 pa 0x3ef5c000 va 0x3ef5c000 pages 0x1 attr 0x8 > type 0x4 pa 0x4000 va 0x4000 pages 0xbc000 attr 0x8 > type 0xb pa 0xfe10 va 0x3d366a pages 0x1 attr 0x8000 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2021 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 7.0 (RAMDISK) #1249: Mon Sep 27 20:10:08 MDT 2021 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK > real mem = 4124962816 (3933MB) > avail mem = 3961278464 (3777MB) > random: good seed from bootblocks > mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3 >
sony vaio laptop - apm adapter state
Hi Misc, A fresh install of 6.9+syspatch on a 2012-ish Sony Vaio Laptop (VPCS11FG) only physical change pre-install was swapping the 320 hdd with 250 ssd. It's a vanila install, with 'apmd' enabled + flag '-A' for adaptive/auto cpu-freq. All the other laptop things seem to be working. eg; wifi, suspend. (well the screen brightness controls are not mapped but need to research that) APM itself seems to be doing its thing, however...the output of 'apm' A/C adapter state: is not representive of the physical connection .. and will only show the state that was booted. Removing the A/C does not change state.. (but battery % does correctly come down over time). Restarting APMD does not change state. if rebooted on battery only, apm state = 'not connected' but when power is re-connected, and battery commences charge, yet the state remains "not connected" - a bit weird. Being an older laptop, there is a physical led that illuminates correctly when the A/C is connected. Checking in debug mode "# apmd -d" yields an ioctl error. (below) In summary, the plug state is not being realised by apmd. i cant see any events in /var/log/messages, or ../daemon log below are outputs of uname -a sysctl hw apm apm -d appreciate any feeback or guidance. thanks in advance. . vaio$ uname -a OpenBSD vaio.local 6.9 GENERIC.MP#4 amd64 vaio$ sysctl hw hw.machine=amd64 hw.model=Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz hw.ncpu=4 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:8e9a4a21ca42676c,cd0: hw.diskcount=2 hw.sensors.cpu0.temp0=46.00 degC hw.sensors.acpibat0.volt0=10.80 VDC (voltage) hw.sensors.acpibat0.volt1=3.81 VDC (current voltage) hw.sensors.acpibat0.power0=14.95 W (rate) hw.sensors.acpibat0.watthour0=42.51 Wh (last full capacity) hw.sensors.acpibat0.watthour1=0.40 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.38 Wh (low capacity) hw.sensors.acpibat0.watthour3=36.90 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=57.24 Wh (design capacity) hw.sensors.acpibat0.raw0=2 (battery charging), OK hw.sensors.acpiac0.indicator0=Off (power supply) hw.sensors.acpibtn1.indicator0=On (lid open) hw.sensors.acpitz0.temp0=47.00 degC (zone temperature) hw.sensors.acpidock0.indicator0=Off (not docked), UNKNOWN hw.sensors.itherm0.temp1=47.00 degC (Core 1) hw.sensors.itherm0.temp4=49.00 degC (CPU/GPU Max temp) hw.sensors.itherm0.temp9=49.00 degC (GPU/Memory controller abs.) hw.sensors.itherm0.temp10=59.00 degC (PCH abs.) hw.sensors.itherm0.power0=8.00 W (CPU power consumption) hw.cpuspeed=933 hw.setperf=0 hw.vendor=Sony Corporation hw.product=VPCS113FG hw.version=C1043B81 hw.serialno=<> hw.uuid=407add24-c1dd-de11-<> hw.physmem=3932688384 hw.usermem=3919343616 hw.ncpufound=4 hw.allowpowerdown=1 hw.perfpolicy=auto hw.smt=0 hw.ncpuonline=2 vaio$ apm Battery state: high, 86% remaining, 147 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (933 MHz) vaio$ doas apmd -d battery status: high. external power status: not connected. estimated battery life 87% (149 minutes) can't disable driver messages, error: Inappropriate ioctl for device apmevent index 0 apmevent 0006 index 53 apmevent 0006 index 54 apmevent 0006 index 55 apmevent 0006 index 56 apmevent 0006 index 57 apmevent 0006 index 58 thanks for looking -SUB
