ACPI kernel panic in first boot after new OpenBSD install

[Shivam Gupta]

Hello all,

I have just installed the OpenBSD on a ASUS tuf f15 gaming laptop,
installation went very smooth.

But I soon as I reboot the computer, it put me in ddb shell and there was a
kernel panic related to acpi.

I searched on internet, and tried to update my bios to the latest version
but that did not help. I tried disabling the acpi but that also not worked,
same result.

I followed
https://www.reddit.com/r/openbsd/comments/150jl5y/acpi_error_at_first_boot_on_dell_inspiron_15_3593/
to
get
https://bugzilla.kernel.org/show_bug.cgi?id=202585, here they said it is
bios bug so closed it.

But bios update did not solve the problem, so I am wondering if there is
any work around of this issue.

I have attached one picture of kernel panic and one with show panic and
trace command on ddb.

Images link -

https://postimg.cc/gallery/KYg665H

Regards,
Shivam

Re: OpenBSD on Dell Wyse 3040 N10D - Successful installation and possible problem with ACPI

[Stuart Henderson]

On 2023-12-18, Luca Di Gregorio  wrote:
> The system booted, but I saw that it stopped unexpectedly after
> some time (hours or minutes) without any apparent reason.
>
> dmesg said 'acpicpu0 ... bad value ...'
> (Unfortunately I don't have a copy of this dmesg).

Use sendbug as root to create a bug report including acpi tables.
(you may want to sendbug -P > somefile and copy that elsewhere if the
machine isn't setup for email). Preferably with an unmodified kernel
so that the dmesg is complete.

Try to get a copy of the full error message too.

> So, I added these lines in /etc/bsd.re-config, to disable ACPI drivers at
> boot:
> disable acpi
> disable acpitz
> disable acpitz*
> disable acpicpu
> disable acpicpu*
> disable acpibat
> disable acpibat*
> disable acpipwrres
> disable acpipwrres*
> disable acpiprt*

why all these, when you only had an issue with acpicpu?

(since acpi is involved in so much of running the system, often
including thermal controls, that's best avoided).

> I'm not skilled enough to go further in the investigation, hopefully
> someone more skilled than me will go on deeper and discover
> the exact issue causing the unexpected stops.

I don't think there's enough information yet for somebody who doesn't
have the hardware to do anything to help.

OpenBSD on Dell Wyse 3040 N10D - Successful installation and possible problem with ACPI

[Luca Di Gregorio]

I managed to install OpenBSD on Dell Wyse 3040.

I chose gpt (not mbr).
I edited the automatic partition scheme created by the installer
because the eMMC is only 8Gb.
Do not delete sd0i when resizing.
Disklabel is available below in this email.

After the installation of the components, ->before<- making all devices
nodes:
# !
# mkdir /mnt/boot
# mount /dev/sd0i /mnt/boot
# rm /mnt/boot/EFI <-- it is a file, a directory is expected instead
# mkdir /mnt/boot/EFI
# mkdir /mnt/boot/EFI/BOOT
# umount /mnt/boot
# exit

Go ahead making device nodes

The system booted, but I saw that it stopped unexpectedly after
some time (hours or minutes) without any apparent reason.

dmesg said 'acpicpu0 ... bad value ...'
(Unfortunately I don't have a copy of this dmesg).

So, I added these lines in /etc/bsd.re-config, to disable ACPI drivers at
boot:
disable acpi
disable acpitz
disable acpitz*
disable acpicpu
disable acpicpu*
disable acpibat
disable acpibat*
disable acpipwrres
disable acpipwrres*
disable acpiprt*

(Some lines are repeated with * because I don't know the exact syntax).

# echo "boot" > /etc/boot.conf
(I don't know why, but /bsd doesn't start after the default 5 sec timeout)

and rebooted.

It seems that now I don't have any unexpected stop.

I'm not skilled enough to go further in the investigation, hopefully
someone more skilled than me will go on deeper and discover
the exact issue causing the unexpected stops.





# fdisk sd0
Disk: sd0   Usable LBA: 34 to 15269854 [15269888 Sectors]
   #: type [   start: size ]

   0: EFI Sys  [  64:   532480 ]
   1: OpenBSD  [  532544: 14737311 ]




# disklabel -p g sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Hynix H8G4a
duid: b2427e536cde59f2
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 950
total sectors: 15269888 # total bytes: 7.3G
boundstart: 532544
boundend: 15269855

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a: 6.8G  1060320  4.2BSD   2048 16384 12960 # /
  b: 0.3G   532544swap# none
  c: 7.3G0  unused
  i: 0.3G   64   MSDOS


# dmesg
OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec  8 15:39:04 MST 2023
r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 2018394112 (1924MB)
avail mem = 1937539072 (1847MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7a9ee000 (55 entries)
bios0: vendor Dell Inc. version "1.2.1" date 05/24/2017
bios0: Dell Inc. Wyse 3040 Thin Client
efi0 at bios0: UEFI 2.4
efi0: American Megatrends rev 0x5000b
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI SSDT HPET
SSDT SSDT SSDT LPIT BCFG PRAM CSRT WDAT WDAT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.02 MHz, 06-4c-04, patch
0411
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 79MHz
cpu0: mwait min=64, max=64, C-substates=0.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.04 MHz, 06-4c-04, patch
0411
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.04 MHz, 06-4c-04, patch
0411
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,

Re: High ACPI CPU load

[Brian Conway]

On Sat, Jul 15, 2023, at 5:38 PM, Julian Huhn wrote:
> On Sat, Jul 15, 2023 at 06:05:06PM +, Mike Larkin wrote:
>>On Sat, Jul 15, 2023 at 04:34:20PM +0200, Julian Huhn wrote:
>>> Since I got many DMARC rejection mails and therefore don't know how many
>>> people this mail reached at all, once again with less restrictive DMARC
>>> settings.
>>>
>>> On Sat, Jul 15, 2023 at 02:28:56PM +0200, Julian Huhn wrote:
>>> > Moin!
>>> >
>>> > A few weeks ago, I put a new system into operation, where I notice a
>>> > permanently high CPU load. With the help of top it appears that
>>> > permanently the process acpi0 is executed.
>>> >
>>> > Is this a bug?
>>> >
>>> > I'm happy to help with more logs, if you tell me what you need.
>>> >
>>> > --Huhn
>>> >
>>
>>This is a stuck GPE. This board in particular is a known issue; search
>>the lists.
>>
>>mbuhl@ suggested a few months back that I get one of these machines to fix
>>the issue, but when I started looking at it, the simplest fix was to just
>>install a new bios.  Since this is likely one of these super cheap 4 port
>>igc(4) aliexpress "firewall PCs", you may need to search a bit to find a
>>compatible bios since most of these don't have a real brand site associated
>>with them.
>>
>>FWIW, the machines with "techvision" bios (like yours) exhibit this issue.
>>Mine had techvision bios (and the same problem) before I flashed it to the
>>image described below.
>>
>>You need to find this bios:
>>
>>bios0: vendor American Megatrends International, LLC. version "JK4LV107" date 
>>04/17/2023
>
> I just found this Reddit Post [0], describing a related issue with this 
> kind of board. There's also a download link [1] in the comments for the 
> bios update. As soon as I found some time I will install the update. 
> Thanks!
>
>>That one works on my machine, with exactly the same config as yours. No
>>more ACPI GPE storm.
>>
>>I don't have the link anymore for where I found the BIOS image, but I
>>think it was on servethehome in one of the long threads about these
>>machines. You need to do some digging.
>>
>>While the root cause may be due to us lacking some driver for the device
>>owning that GPE, or our lack of activating GPEs based on attached
>>hardware, the 5-minute bios update fix was a good enough fix for me and
>>I moved on to other things.
>>
>>The other lesson I learned is that you get what you pay for; buying $100
>>PCs from aliexpress means you're just going to be paying for it somewhere
>>else. In this case, dealing with shoddy engineering and unsupported boards.
>>
>>-ml
>>
>>>
>
> [0] 
> https://www.reddit.com/r/PFSENSE/comments/14vv90w/topton_5105_n6005_owners_any_issues_running_on/
> [1] 
> https://pan.x86pi.cn/BIOS%E6%9B%B4%E6%96%B0/1.Intel%E8%BF%B7%E4%BD%A0%E4%B8%BB%E6%9C%BA%E7%B3%BB%E5%88%97BIOS/N5105%20V3-V5%20%E5%BE%AE%E7%A0%81%E6%9B%B4%E6%96%B023-04-18

I can confirm that the linked BIOS update resolves the stuck GPE on my board. I 
ended up using unetbootin to get the ISO in a state that my board was willing 
to boot and flash.

I appear to have lost the ability to redirect the BIOS via serial console with 
this update, but as noted, you get what you pay for.

Thanks all.

Brian

Re: High ACPI CPU load

[Julian Huhn]

On Sat, Jul 15, 2023 at 06:05:06PM +, Mike Larkin wrote:

On Sat, Jul 15, 2023 at 04:34:20PM +0200, Julian Huhn wrote:

Since I got many DMARC rejection mails and therefore don't know how many
people this mail reached at all, once again with less restrictive DMARC
settings.

On Sat, Jul 15, 2023 at 02:28:56PM +0200, Julian Huhn wrote:
> Moin!
>
> A few weeks ago, I put a new system into operation, where I notice a
> permanently high CPU load. With the help of top it appears that
> permanently the process acpi0 is executed.
>
> Is this a bug?
>
> I'm happy to help with more logs, if you tell me what you need.
>
> --Huhn
>


This is a stuck GPE. This board in particular is a known issue; search
the lists.

mbuhl@ suggested a few months back that I get one of these machines to fix
the issue, but when I started looking at it, the simplest fix was to just
install a new bios.  Since this is likely one of these super cheap 4 port
igc(4) aliexpress "firewall PCs", you may need to search a bit to find a
compatible bios since most of these don't have a real brand site associated
with them.

FWIW, the machines with "techvision" bios (like yours) exhibit this issue.
Mine had techvision bios (and the same problem) before I flashed it to the
image described below.

You need to find this bios:

bios0: vendor American Megatrends International, LLC. version "JK4LV107" date 
04/17/2023


I just found this Reddit Post [0], describing a related issue with this 
kind of board. There's also a download link [1] in the comments for the 
bios update. As soon as I found some time I will install the update. 
Thanks!



That one works on my machine, with exactly the same config as yours. No
more ACPI GPE storm.

I don't have the link anymore for where I found the BIOS image, but I
think it was on servethehome in one of the long threads about these
machines. You need to do some digging.

While the root cause may be due to us lacking some driver for the device
owning that GPE, or our lack of activating GPEs based on attached
hardware, the 5-minute bios update fix was a good enough fix for me and
I moved on to other things.

The other lesson I learned is that you get what you pay for; buying $100
PCs from aliexpress means you're just going to be paying for it somewhere
else. In this case, dealing with shoddy engineering and unsupported boards.

-ml


> # top -S
> load averages:  1.01,  0.99,  1.00blech02.trust.dtm.huhn.dev
> 14:08:31
> 85 processes: 81 idle, 4 on processor  up 3 days 16:04:10
> CPU0 states:  0.1% user,  0.0% nice, 16.3% sys,  0.5% spin, 75.6% intr,
> 7.5% idle
> CPU1 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% intr,
> 95.7% idle
> CPU2 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% intr,
> 95.7% idle
> CPU3 states:  0.1% user,  0.0% nice,  0.7% sys,  2.5% spin,  0.0% intr,
> 96.7% idle
> Memory: Real: 33M/10G act/tot Free: 21G Cache: 9303M Swap: 0K/32G
>
>  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU
> COMMAND
> 57981 root  3400K 1976K onproc/0  -   832:27 15.48%
> acpi0
> 18343 root  2800K 1976K onproc/3  -85.2H  0.00%
> idle3
> 71885 root -2200K 1976K sleep/1   -84.3H  0.00%
> idle1
> 6761 root  2800K 1976K onproc/2  -84.3H  0.00% idle2
> 7152 root -2200K 1976K sleep/0   -69.4H  0.00% idle0
> 95844 root  1800K 1976K sleep/2   syncer0:48  0.00%
> update
> 92641 root  1000K 1976K sleep/1   bored 0:40  0.00%
> softnet
> 10729 root  1000K 1976K sleep/3   bored 0:31  0.00%
> sensors
> 31290 root  1000K 1976K sleep/2   bored 0:22  0.00%
> softnet
> 23268 _pflogd40  764K 1588K sleep/2   bpf   0:22  0.00%
> pflogd
> 7279 root  1000K 1976K sleep/1   bored 0:21  0.00% srdis
> 24604 jhuhn  20 1460K 3448K sleep/1   kqread0:14  0.00% sshd
> 9279 root -2200K 1976K sleep/0   bored 0:10  0.00%
> softclock
> 35785 root 105   200K 1976K sleep/2   pgzero0:10  0.00%
> zerothread
> 21023 root  100  476K  972K sleep/2   nanoslp   0:06  0.00%
> sensorsd
> 82628 root  1000K 1976K sleep/1   bored 0:05  0.00%
> systqmp
> 76212 root  1000K 1976K sleep/2   bored 0:05  0.00%
> softnet
> 52512 root  1000K 1976K sleep/1   bored 0:04  0.00%
> systq
>
> # dmesg
> OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34180132864 (32596MB)
> avail mem = 33124827136 (31590MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> 

Re: High ACPI CPU load

[Mike Larkin]

On Sat, Jul 15, 2023 at 04:34:20PM +0200, Julian Huhn wrote:
> Since I got many DMARC rejection mails and therefore don't know how many
> people this mail reached at all, once again with less restrictive DMARC
> settings.
>
> On Sat, Jul 15, 2023 at 02:28:56PM +0200, Julian Huhn wrote:
> > Moin!
> >
> > A few weeks ago, I put a new system into operation, where I notice a
> > permanently high CPU load. With the help of top it appears that
> > permanently the process acpi0 is executed.
> >
> > Is this a bug?
> >
> > I'm happy to help with more logs, if you tell me what you need.
> >
> > --Huhn
> >

This is a stuck GPE. This board in particular is a known issue; search
the lists.

mbuhl@ suggested a few months back that I get one of these machines to fix
the issue, but when I started looking at it, the simplest fix was to just
install a new bios.  Since this is likely one of these super cheap 4 port
igc(4) aliexpress "firewall PCs", you may need to search a bit to find a
compatible bios since most of these don't have a real brand site associated
with them.

FWIW, the machines with "techvision" bios (like yours) exhibit this issue.
Mine had techvision bios (and the same problem) before I flashed it to the
image described below.

You need to find this bios:

bios0: vendor American Megatrends International, LLC. version "JK4LV107" date 
04/17/2023

That one works on my machine, with exactly the same config as yours. No
more ACPI GPE storm.

I don't have the link anymore for where I found the BIOS image, but I
think it was on servethehome in one of the long threads about these
machines. You need to do some digging.

While the root cause may be due to us lacking some driver for the device
owning that GPE, or our lack of activating GPEs based on attached
hardware, the 5-minute bios update fix was a good enough fix for me and
I moved on to other things.

The other lesson I learned is that you get what you pay for; buying $100
PCs from aliexpress means you're just going to be paying for it somewhere
else. In this case, dealing with shoddy engineering and unsupported boards.

-ml

> > # top -S
> > load averages:  1.01,  0.99,  1.00blech02.trust.dtm.huhn.dev
> > 14:08:31
> > 85 processes: 81 idle, 4 on processor  up 3 days 16:04:10
> > CPU0 states:  0.1% user,  0.0% nice, 16.3% sys,  0.5% spin, 75.6% intr,
> > 7.5% idle
> > CPU1 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% intr,
> > 95.7% idle
> > CPU2 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% intr,
> > 95.7% idle
> > CPU3 states:  0.1% user,  0.0% nice,  0.7% sys,  2.5% spin,  0.0% intr,
> > 96.7% idle
> > Memory: Real: 33M/10G act/tot Free: 21G Cache: 9303M Swap: 0K/32G
> >
> >  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU
> > COMMAND
> > 57981 root  3400K 1976K onproc/0  -   832:27 15.48%
> > acpi0
> > 18343 root  2800K 1976K onproc/3  -85.2H  0.00%
> > idle3
> > 71885 root -2200K 1976K sleep/1   -84.3H  0.00%
> > idle1
> > 6761 root  2800K 1976K onproc/2  -84.3H  0.00% idle2
> > 7152 root -2200K 1976K sleep/0   -69.4H  0.00% idle0
> > 95844 root  1800K 1976K sleep/2   syncer0:48  0.00%
> > update
> > 92641 root  1000K 1976K sleep/1   bored 0:40  0.00%
> > softnet
> > 10729 root  1000K 1976K sleep/3   bored 0:31  0.00%
> > sensors
> > 31290 root  1000K 1976K sleep/2   bored 0:22  0.00%
> > softnet
> > 23268 _pflogd40  764K 1588K sleep/2   bpf   0:22  0.00%
> > pflogd
> > 7279 root  1000K 1976K sleep/1   bored 0:21  0.00% srdis
> > 24604 jhuhn  20 1460K 3448K sleep/1   kqread0:14  0.00% sshd
> > 9279 root -2200K 1976K sleep/0   bored 0:10  0.00%
> > softclock
> > 35785 root 105   200K 1976K sleep/2   pgzero0:10  0.00%
> > zerothread
> > 21023 root  100  476K  972K sleep/2   nanoslp   0:06  0.00%
> > sensorsd
> > 82628 root  1000K 1976K sleep/1   bored 0:05  0.00%
> > systqmp
> > 76212 root  1000K 1976K sleep/2   bored 0:05  0.00%
> > softnet
> > 52512 root  1000K 1976K sleep/1   bored 0:04  0.00%
> > systq
> >
> > # dmesg
> > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 34180132864 (32596MB)
> > avail mem = 33124827136 (31590MB)
> > random: good seed from bootblocks
> > mpath0 at 

Re: High ACPI CPU load

[Julian Huhn]

Since I got many DMARC rejection mails and therefore don't know how many 
people this mail reached at all, once again with less restrictive DMARC 
settings.


On Sat, Jul 15, 2023 at 02:28:56PM +0200, Julian Huhn wrote:

Moin!

A few weeks ago, I put a new system into operation, where I notice a 
permanently high CPU load. With the help of top it appears that 
permanently the process acpi0 is executed.


Is this a bug?

I'm happy to help with more logs, if you tell me what you need.

--Huhn

# top -S
load averages:  1.01,  0.99,  1.00blech02.trust.dtm.huhn.dev 
14:08:31

85 processes: 81 idle, 4 on processor  up 3 days 16:04:10
CPU0 states:  0.1% user,  0.0% nice, 16.3% sys,  0.5% spin, 75.6% 
intr,  7.5% idle
CPU1 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% 
intr, 95.7% idle
CPU2 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% 
intr, 95.7% idle
CPU3 states:  0.1% user,  0.0% nice,  0.7% sys,  2.5% spin,  0.0% 
intr, 96.7% idle

Memory: Real: 33M/10G act/tot Free: 21G Cache: 9303M Swap: 0K/32G

 PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU   
COMMAND
57981 root  3400K 1976K onproc/0  -   832:27 15.48% 
acpi0
18343 root  2800K 1976K onproc/3  -85.2H  0.00% 
idle3
71885 root -2200K 1976K sleep/1   -84.3H  0.00% 
idle1

6761 root  2800K 1976K onproc/2  -84.3H  0.00% idle2
7152 root -2200K 1976K sleep/0   -69.4H  0.00% idle0
95844 root  1800K 1976K sleep/2   syncer0:48  0.00% 
update
92641 root  1000K 1976K sleep/1   bored 0:40  0.00% 
softnet
10729 root  1000K 1976K sleep/3   bored 0:31  0.00% 
sensors
31290 root  1000K 1976K sleep/2   bored 0:22  0.00% 
softnet
23268 _pflogd40  764K 1588K sleep/2   bpf   0:22  0.00% 
pflogd

7279 root  1000K 1976K sleep/1   bored 0:21  0.00% srdis
24604 jhuhn  20 1460K 3448K sleep/1   kqread0:14  0.00% sshd
9279 root -2200K 1976K sleep/0   bored 0:10  0.00% 
softclock
35785 root 105   200K 1976K sleep/2   pgzero0:10  0.00% 
zerothread
21023 root  100  476K  972K sleep/2   nanoslp   0:06  0.00% 
sensorsd
82628 root  1000K 1976K sleep/1   bored 0:05  0.00% 
systqmp
76212 root  1000K 1976K sleep/2   bored 0:05  0.00% 
softnet
52512 root  1000K 1976K sleep/1   bored 0:04  0.00% 
systq


# dmesg
OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34180132864 (32596MB)
avail mem = 33124827136 (31590MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x78d77000 (116 entries)
bios0: vendor Techvision, LLC. version "5.19" date 09/16/2022
bios0: Techvision TVI7309X
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x50013
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT 
SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SPCR TPM2 WSMT FPDT
acpi0: wakeup devices PEGP(S3) PEGP(S3) PEGP(S3) PEGP(S3) PS2K(S3) 
PS2M(S3) RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) RP03(S3) PXSX(S3) 
RP04(S3) PXSX(S3) RP05(S3) PXSX(S3) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc000, bus 0-255
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2893.74 MHz, 06-9c-00
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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache

cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2893.74 MHz, 06-9c-00
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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 

High ACPI CPU load

[Julian Huhn]

Moin!

A few weeks ago, I put a new system into operation, where I notice a 
permanently high CPU load. With the help of top it appears that 
permanently the process acpi0 is executed.


Is this a bug?

I'm happy to help with more logs, if you tell me what you need.

--Huhn

# top -S
load averages:  1.01,  0.99,  1.00blech02.trust.dtm.huhn.dev 
14:08:31

85 processes: 81 idle, 4 on processor  up 3 days 16:04:10
CPU0 states:  0.1% user,  0.0% nice, 16.3% sys,  0.5% spin, 75.6% intr,  
7.5% idle
CPU1 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% intr, 
95.7% idle
CPU2 states:  0.1% user,  0.0% nice,  0.9% sys,  3.3% spin,  0.0% intr, 
95.7% idle
CPU3 states:  0.1% user,  0.0% nice,  0.7% sys,  2.5% spin,  0.0% intr, 
96.7% idle

Memory: Real: 33M/10G act/tot Free: 21G Cache: 9303M Swap: 0K/32G

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU 
  COMMAND
57981 root  3400K 1976K onproc/0  -   832:27 15.48% 
acpi0
18343 root  2800K 1976K onproc/3  -85.2H  0.00% 
idle3
71885 root -2200K 1976K sleep/1   -84.3H  0.00% 
idle1

6761 root  2800K 1976K onproc/2  -84.3H  0.00% idle2
7152 root -2200K 1976K sleep/0   -69.4H  0.00% idle0
95844 root  1800K 1976K sleep/2   syncer0:48  0.00% 
update
92641 root  1000K 1976K sleep/1   bored 0:40  0.00% 
softnet
10729 root  1000K 1976K sleep/3   bored 0:31  0.00% 
sensors
31290 root  1000K 1976K sleep/2   bored 0:22  0.00% 
softnet
23268 _pflogd40  764K 1588K sleep/2   bpf   0:22  0.00% 
pflogd

7279 root  1000K 1976K sleep/1   bored 0:21  0.00% srdis
24604 jhuhn  20 1460K 3448K sleep/1   kqread0:14  0.00% sshd
9279 root -2200K 1976K sleep/0   bored 0:10  0.00% 
softclock
35785 root 105   200K 1976K sleep/2   pgzero0:10  0.00% 
zerothread
21023 root  100  476K  972K sleep/2   nanoslp   0:06  0.00% 
sensorsd
82628 root  1000K 1976K sleep/1   bored 0:05  0.00% 
systqmp
76212 root  1000K 1976K sleep/2   bored 0:05  0.00% 
softnet
52512 root  1000K 1976K sleep/1   bored 0:04  0.00% 
systq


# dmesg
OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34180132864 (32596MB)
avail mem = 33124827136 (31590MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x78d77000 (116 entries)
bios0: vendor Techvision, LLC. version "5.19" date 09/16/2022
bios0: Techvision TVI7309X
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x50013
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT 
SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR SSDT SPCR TPM2 WSMT FPDT
acpi0: wakeup devices PEGP(S3) PEGP(S3) PEGP(S3) PEGP(S3) PS2K(S3) 
PS2M(S3) RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) RP03(S3) PXSX(S3) RP04(S3) 
PXSX(S3) RP05(S3) PXSX(S3) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc000, bus 0-255
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2893.74 MHz, 06-9c-00
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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache

cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) N5105 @ 2.00GHz, 2893.74 MHz, 06-9c-00
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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 
64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache

cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celero

Re: load custom acpi table

[Mike Larkin]

On Mon, Jun 19, 2023 at 08:55:10AM +0300, S V wrote:
> Hello, list!
>
> Is it possible to load custom acpi table on boot ?
>
> in FreeBSD it was possible by strings in conf like
>
> acpi_dsdt_load="YES" acpi_dsdt_name="filename.aml"

no

load custom acpi table

[S V]

Hello, list!

Is it possible to load custom acpi table on boot ?

in FreeBSD it was possible by strings in conf like

acpi_dsdt_load="YES" acpi_dsdt_name="filename.aml"

Re: Panic in 7.2 and snapshots at boot due to acpi bios error

[Jason Tubnor]

From: owner-m...@openbsd.org  on behalf of Jeff Roach 

Sent: Monday, 23 January 2023 9:08 PM
To: misc@openbsd.org 
Subject: Panic in 7.2 and snapshots at boot due to acpi bios error 
 
Hi!  Really love OpenBSD and would like to get it working on my Samsung
Galaxy Book Flex2 Alpha.  NP730QDA-KA3US.  Just offering this up because I
can't send a dmesg.  

I believe it may be a bug in the acpi bios code for which there is no
firmware update.  It boots, linux, win 10/11, net and freebsds fine with
acpi errors.  


We hit this in the Lenovo ThinkStation m70s Gen 3 during hardware validation. A 
workaround was provided and allowed for more data to be sent but the workaround 
was not deemed to be acceptable.

Here is the original bug and thread:

https://marc.info/?l=openbsd-bugs=166674319711567=2

Good to see that it isn't only a Lenovo thing.

Panic in 7.2 and snapshots at boot due to acpi bios error

[Jeff Roach]

Hi!  Really love OpenBSD and would like to get it working on my Samsung
Galaxy Book Flex2 Alpha.  NP730QDA-KA3US.  Just offering this up because I
can't send a dmesg.  I get a kernel panic at boot with the following screen,

https://photos.app.goo.gl/2NNHiTtG6LbTc5nx6

I believe it may be a bug in the acpi bios code for which there is no
firmware update.  It boots, linux, win 10/11, net and freebsds fine with
acpi errors.  I tried to disable acpi to see if I could get it installed
and the installer ran but could not find the ethernet, wifi or ssd.

Can anyone help with this?  I'd be glad to provide more info if there is a
way.

Thanks,

Jeff

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Theo de Raadt]

Mike Larkin  wrote:

> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS setting enabled, I
> > experience slowdown consistently.
> >
> > I am sorry but I don't know enough technically as to discern why. I am
> > simply reporting my user experience. I will re-disable the Thunderbolt
> > assist for now.
> >
> 
> If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
> then we can make forward progress (we need an acpidump of that machine
> also).
> 
> Otherwise, its like throwing darts in the dark.

Or, someone with a machine which has the problem can give it to Mike,
or a few other developers who understand this problem area.

I'm not joking.  Give it.  It would be a public service.

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Daniel Wilkins]

On Wed, Sep 29, 2021 at 06:29:08PM -0700, Mike Larkin wrote:
> On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> > After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> > slowdown on my T480. Previously, I experienced slowdown after power cycling
> > my machine occasionally. Currently, with this BIOS setting enabled, I
> > experience slowdown consistently.
> >
> > I am sorry but I don't know enough technically as to discern why. I am
> > simply reporting my user experience. I will re-disable the Thunderbolt
> > assist for now.
> >
>
> If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
> then we can make forward progress (we need an acpidump of that machine
> also).
>
> Otherwise, its like throwing darts in the dark.
>
> -ml

I could give it a shot. Do you want all three possible states for the
dumps? (disabled, working. Disabled, looped acpi0. Enabled, working.)

It probably won't be until tomorrow since it's already pretty late,
though.

Danny

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Mike Larkin]

On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote:
> After enabling "BIOS Thunderbolt Assist", I experience consistent machine
> slowdown on my T480. Previously, I experienced slowdown after power cycling
> my machine occasionally. Currently, with this BIOS setting enabled, I
> experience slowdown consistently.
>
> I am sorry but I don't know enough technically as to discern why. I am
> simply reporting my user experience. I will re-disable the Thunderbolt
> assist for now.
>

If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck
then we can make forward progress (we need an acpidump of that machine
also).

Otherwise, its like throwing darts in the dark.

-ml

> On 9/29/21 2:58 PM, David Anthony wrote:
> > Another T480 user who has noticed the same problem. Per advice given,
> > I've just enabled "BIOS Thunderbolt Assist". I will report back if I
> > notice the problem persists.
> >
> > On 9/19/21 4:50 AM, Daniel Wilkins wrote:
> > > I've ran into this on my T480, it seems most consistently triggered
> > > by power
> > > cycles caused by running out of battery. The bug's existed for quite
> > > a few
> > > years (I think I first noticed it in 2019.) If I recall correctly I've
> > > posted it to the list a couple of times but I don't think any
> > > concrete answers
> > > ever emerged; your report is more thorough than mine were though.
> > > I do remember that it never happened on my T430, but that's quite the
> > > hardware gap.
> > >
> >
>

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[David Anthony]

After enabling "BIOS Thunderbolt Assist", I experience consistent 
machine slowdown on my T480. Previously, I experienced slowdown after 
power cycling my machine occasionally. Currently, with this BIOS setting 
enabled, I experience slowdown consistently.


I am sorry but I don't know enough technically as to discern why. I am 
simply reporting my user experience. I will re-disable the Thunderbolt 
assist for now.


On 9/29/21 2:58 PM, David Anthony wrote:
Another T480 user who has noticed the same problem. Per advice given, 
I've just enabled "BIOS Thunderbolt Assist". I will report back if I 
notice the problem persists.


On 9/19/21 4:50 AM, Daniel Wilkins wrote:
I've ran into this on my T480, it seems most consistently triggered 
by power
cycles caused by running out of battery. The bug's existed for quite 
a few

years (I think I first noticed it in 2019.) If I recall correctly I've
posted it to the list a couple of times but I don't think any 
concrete answers

ever emerged; your report is more thorough than mine were though.
I do remember that it never happened on my T430, but that's quite the
hardware gap.

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[David Anthony]

Another T480 user who has noticed the same problem. Per advice given, 
I've just enabled "BIOS Thunderbolt Assist". I will report back if I 
notice the problem persists.


On 9/19/21 4:50 AM, Daniel Wilkins wrote:

I've ran into this on my T480, it seems most consistently triggered by power
cycles caused by running out of battery. The bug's existed for quite a few
years (I think I first noticed it in 2019.) If I recall correctly I've
posted it to the list a couple of times but I don't think any concrete answers
ever emerged; your report is more thorough than mine were though.
I do remember that it never happened on my T430, but that's quite the
hardware gap.

Re: SOLVED Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Daniel Wilkins]

On Wed, Sep 29, 2021 at 11:47:34AM -0600, Theo de Raadt wrote:
> It would be great if someone figures out why "BIOS Thunderbolt Assist"
> disable, causes a pin to get stuck on resume, and/or figures out how we
> can recognize to handle/clear the event.

The detail in my BIOS options specifically mentions it as a Linux
workaround. Obviously patches couldn't be imported but I'll poke
around to see if there's any discussion/a description of what
exactly is happening.

Aside from that is there any data I can send y'all? Jonathan's built up
a pretty comprehensive set of dmesgs at this point, it seems like.

(No need to cc me, I'm on misc@)

Danny

SOLVED Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Jonathan Thornburg]

Hi,

On 2021-09-28 14>18>49, Daniel Wilkins wrote
> All you have to do is go into your bios' settings and turn on
> "BIOS Thunderbolt Assist" then everything will work 100% fine.
> 
> Thanks to jcs on IRC for pointing me at that (dunno what his
> email is.)

Success!  With this (and the 7.0 snapshot I installed yesterday; dmesg
in my message )
the problem is gone, and my T580 now does suspend/resume perfectly
(including idling with CPU usage under 1%).

A big thank-you to Daniel and to jcs (I'm guessing that's Joshua Stein,
https://jcs.org/) for the solution, and to Theo and Mike for their
suggestions too!

Thanks again,

--
-- "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: SOLVED Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Theo de Raadt]

Jonathan Thornburg  wrote:

> On 2021-09-28 14>18>49, Daniel Wilkins wrote
> > All you have to do is go into your bios' settings and turn on
> > "BIOS Thunderbolt Assist" then everything will work 100% fine.
> > 
> > Thanks to jcs on IRC for pointing me at that (dunno what his
> > email is.)
> 
> Success!  With this (and the 7.0 snapshot I installed yesterday; dmesg
> in my message )
> the problem is gone, and my T580 now does suspend/resume perfectly
> (including idling with CPU usage under 1%).
> 
> A big thank-you to Daniel and to jcs (I'm guessing that's Joshua Stein,
> https://jcs.org/) for the solution, and to Theo and Mike for their
> suggestions too!

It would be great if someone figures out why "BIOS Thunderbolt Assist"
disable, causes a pin to get stuck on resume, and/or figures out how we
can recognize to handle/clear the event.

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Daniel Wilkins]

On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote:
> There are a few people who have experience with this.  Maybe one of
> them will mail you privately.
>

I'm glad this thread suddenly got revived, since I tried to find it
in my backlog but it got lost.

All you have to do is go into your bios' settings and turn on
"BIOS Thunderbolt Assist" then everything will work 100% fine.

Thanks to jcs on IRC for pointing me at that (dunno what his
email is.)

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Jonathan Thornburg]

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 

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Mike Larkin]

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: 6.9/amd64 runaway acpi process on Thinkpad T580

[Theo de Raadt]

> 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

[Theo de Raadt]

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

[Theo de Raadt]

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

[Jonathan Thornburg]

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

[Daniel Wilkins]

I dunno if this is helpful, but I just unplugged my thinkpad and triggered the 
behavior.

ACPI shot right up, and in this case the "charging" LED has stayed on. I've 
never triggered
it by unplugging before, but the symptoms are the same. The system was under 
some load while
doing so (watching a video in Firefox and extracting a backup.) The last line 
in dmesg also
seems weird to me; it might be a firmware thing, from that.

Danny
OpenBSD 7.0 (GENERIC.MP) #224: Mon Sep 20 11:44:33 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 38362574848 (36585MB)
avail mem = 37183885312 (35461MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x6ecc4000 (63 entries)
bios0: vendor LENOVO version "N24ET49W (1.24 )" date 04/19/2019
bios0: LENOVO 20L50054US
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 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) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) 
RP06(S4) PXSX(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) i5-8350U CPU @ 1.70GHz, 1591.45 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) i5-8350U CPU @ 1.70GHz, 1596.28 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) i5-8350U CPU @ 1.70GHz, 1596.28 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) i5-8350U CPU @ 1.70GHz, 1596.28 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
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz, 1596.28 MHz, 06-8e-0a
cpu4: 
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,AD

Re: 6.9/amd64 runaway acpi process on Thinkpad T580

[Jonathan Thornburg]

I wrote

> During the installation (both in the bsd.rd install script and previously
> when I dropped into the bsd.rd shell to set up softraid-crypto) the machine
> acted incredibly slow, and there was a several-second delay in echoing
> typed characters.  I suspected that it was some device producing spurious
> interrupts, and just let the install run overnight until it finally
> finished.

I neglected to note that I also saw similar behavior with another T580
I previously bought (& then returned when it proved to have hardware
defects).  Combined with Daniel Wilkins' experience with a T480, this
suggests that this is a generic problem with Thinkpad T[45]80.  Does
anyone have a T[45]80 who has *not* seen this 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

[Daniel Wilkins]

I've ran into this on my T480, it seems most consistently triggered by power
cycles caused by running out of battery. The bug's existed for quite a few
years (I think I first noticed it in 2019.) If I recall correctly I've
posted it to the list a couple of times but I don't think any concrete answers
ever emerged; your report is more thorough than mine were though.
I do remember that it never happened on my T430, but that's quite the
hardware gap.

6.9/amd64 runaway acpi process on Thinkpad T580

[Jonathan Thornburg]

I have just installed 6.9-stable/amd64 on a new-to-me (used) Lenovo
Thinkpad T580 (dmesg below).  This was a from-scratch install on a
new-from-the-factory SSD (via booting the 6.9/amd64 bsd.rd from a usb
stick).

During the installation (both in the bsd.rd install script and previously
when I dropped into the bsd.rd shell to set up softraid-crypto) the machine
acted incredibly slow, and there was a several-second delay in echoing
typed characters.  I suspected that it was some device producing spurious
interrupts, and just let the install run overnight until it finally
finished.

After the install (booting into normal multiuser operation) the machine
seemed to work fine at first.  Notably, X "just works", screen brightness
adjust with Fn-F5/Fn-F6 "just works", iwm wifi "just works", and
suspend-to-RAM with Fn/Backspace "just works".

*BUT*, intermittently (maybe 25% of the time?) after a power-cycle and
reboot, there is what appears to be a system process 'acpi0' infinite-looping
(taking 100% of one CPU core, with 'top' showing ~80% system time for that
processor).  Here's a cut-n-paste of the beginning of 'top -S -i -s1'
output in that state, showing the runaway process:

load averages:  1.02,  1.10,  0.86   gold.bkis-orchard.net 00:41:44
134 processes: 130 idle, 4 on processorup  0:19
CPU0:  0.0% user,  0.0% nice, 80.2% sys,  1.0% spin, 17.8% intr,  1.0% idle
CPU1:  0.0% user,  0.0% nice,  0.0% sys,  1.0% spin,  0.0% intr, 99.0% idle
CPU2:  0.0% user,  0.0% nice,  1.0% sys,  2.0% spin,  0.0% intr, 97.0% idle
CPU3:  0.0% user,  0.0% nice,  1.0% sys,  2.0% spin,  0.0% intr, 97.0% idle
Memory: Real: 341M/1548M act/tot Free: 14G Cache: 665M Swap: 0K/34G

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
67563 root  1000K   19M sleep/0   acpi014:48 77.73% acpi0
59020 _x11   20   36M   59M sleep/1   poll  0:48  5.47% Xorg
48374 root   20 8952K   15M sleep/2   select0:09  0.73% perl

Specifying an additional '-H' option to 'top' ("show process threads")
didn't change the output significantly.

FWIW, I have apmd running

# cat /etc/rc.conf.local
apmd_flags='-A -t 60'
vmd_flags=''
xenodm_flags=''
#

apmd appears to be adjusting the CPU clock rate correctly, both now
and on those cold-boots where the infinite-loop problem does not occur.
As I noted above, suspend-to-RAM (via Fn-Backspace, which is the key
combination marked with the usual Thinkpad "moon" icon) "just works".

Is this sort of acpi (?) runaway a known T580 problem?  Neither google
nor the nycbug.org dmesg archive show any OpenBSD T580 dmesg, but I do
see occasional web posts mentioning OpenBSD on a T580.

Below I give my dmesg (from the current boot, the one that produced the
above runaway process).  What other information would be useful to try
to diagnose the problem?

Thanks,
--
-- "Jonathan Thornburg [remove color- to reply]" 
   on the west coast of Canada, eh?

--- begin dmesg ---
OpenBSD 6.9 (GENERIC.MP) #4: Tue Aug 10 08:12:23 MDT 2021

r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16755720192 (15979MB)
avail mem = 16232525824 (15480MB)
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, 1794.33 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 processo

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Andrew Daugherity]

The missing 256 MB memory is probably stolen by the onboard video; it
may be possible to reduce this to a smaller amount via a BIOS setting.
You might also try fiddling with any available ACPI settings, e.g.
sleep states, etc. (IIRC my VIA Epia M had a setting for whether
"sleep" meant S1 or S3.) And I kinda wonder if that unexplained 10-pin
CN2 header might be a serial port?  Although since it doesn't show up
in dmesg, maybe not...

I was about to ask if the ACPI dump differed between PXE vs. hdd boot,
but then I realized that was impossible to check given the crash. :-)
  If you could boot another OS from both hdd and PXE, maybe compare
ACPI dumps to see if the BIOS changes something?

Another workaround would be to 'boot -c' and disable acpi0, but that
of course doesn't help fix the bug.

-Andrew

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[ed]

On Mon, 28 Dec 2020 13:20:29 -0500
Ian Darwin  wrote:

> Boot used Kernel  FromResult
> pxeboot   bsd.rd  tftpOK
> pxeboot   bsd hd0aOK (via
> tftpboot/etc/conf) boot   bsd
> hd0a  panic
> 
> I.e., Boots fine with pxeboot "set device hd0a", but booting exact
> same kernel off same disk via /boot causes panic.

   Hi seems booting process after installation should be straight
   forward. Suggest file a bug report.

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Bryan Steele]

On Tue, Dec 29, 2020 at 12:11:29PM -0500, Ian Darwin wrote:
> On Tue, Dec 29, 2020 at 09:42:59AM -0500, Bryan Steele wrote:
> > On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> > > Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> > > 
> > > Machine is a Wyse C90 - orignially sold as a "thin client" - tiny 
> > > machine, no serial port (ps and trace typed in).
> > > HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> > > Was planning to use it as a wifi bridge, so tiny is fine.
> > > 
> > > "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> > > cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> > > 06-0d-00
> > > RAM: 1GB (despite reported as 3/4 of that)
> > 
> > Long shot, but could you maybe show the output of "machine memory" for
> > both boot/pxeboot? I'm curious if the memory map is reportedly
> > differently between a working boot and a bad one.
> 
> 
> Good suggestion, and indeed, it differs a little:
> 
> Using pxeboot:
> 
> CLIENT MAC ADDR: 00 80 64 xx xx xx GUID: C2020018-0403-0920-EE9A-0080648793AD
> CLIENT IP: 192.168.42.245 MASK: 255.255.255.0 DHCP IP: 192.168.42.254
> GATEWAY IP: 192.168.42.254
> probing: pc0 pci pxe![2.1] mem[546K 765M a20-on]
> disk: hd0+
> net: nac 00:80:64:xx:xx:xx, ip 192.168.42.245, server 192.168.42.254
> >> OpenBSD, i386 PXEBOOT 3.43 boot> machine mem
> Region 0: type 1 at 0x0 for 546KB
> Region 1: type 2 at 0x88800 for 94KB
> Region 2: type 2 at Oxe for 128KB
> Region 3: type 1 at 0x10 for 784192KB
> Region 4: type 3 at Ox2fed for 28KB
> Region 5: type 4 at 0x2fed7000 for 4KB
> Region 6: type 2 at Ox2fed8000 for 160KB
> Region 7: type 2 at Ox2ff0 for 1024KB
> Region 8: type 2 at Ox3000 for 262144KB
> Region 9: type 2 at Oxe000 for 262144KB
> Region 10: type 2 at Oxfec0 for 64KB
> Region 11: type 2 at Oxfee0 for 4KB
> Region 12: type 2 at Oxfff0 for 1024KB
> Low ram: 546KB High ram: 784192KB Total free nemory: 784738KB
> boot>
>  
> Using /boot:
> 
> >> OpenBSD/i386 BOOT 3.44
> boot> machine mem
> Region 0: Type 1 at 0x0x for 631KB
> Region 1: Type 2 at 0x9dc99 for 9KB
> Region 2: type 2 at 0xe for 128kb
> (remainder the same)
> 
> Could Region 1 being so microscopic cause problems? If it got used for 
> anything?
>
Type 2 here means the memory is reserved (not available for use), while
type 1 (and generally 3) can be used by the bootloader or kernel.

> Thx for looking.

No problem, it's interesting that pxeboot actually has less memory
below 1Meg compared to normal /boot, but I guess that makes sense
in that environmnet.

But curious to hear from people more familiar with the boot blocks
have an ideas.

> > > Full dmesg below; full ACPI attached.
> > > 
> > > Boot used Kernel  FromResult
> > > pxeboot   bsd.rd  tftpOK
> > > pxeboot   bsd hd0aOK (via 
> > > tftpboot/etc/conf)
> > > boot  bsd hd0apanic
> > > 
> > > I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> > > kernel off same disk via /boot causes panic.
> > > 
> > > It's an older machine so it's likely a buggy acpi, not worth massive 
> > > investment of time, just wonder if there's an easy workaround.
> > > Presume it's getting something different in some AML, based on where boot 
> > > code loaded from,
> > > or else pxeboot vs boot setting environment slightly differently?
> > > 
> > > On screen after panic:
> > > 
> > > bios0: WYSE C CLASS
> > > acpi0 at bios0: ACPI 3.0
> > > acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> > > Stopped at db_enter+0x4: popl %eb
> > > 
> > > trace:
> > > 
> > > db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> > > panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> > > pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> > > acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> > > aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> > > aml_opreg_pcicfg_handler+0x21
> > > aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> > > aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> > > aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> > > aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> > > aml_parse(d2b4

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Ian Darwin]

On Tue, Dec 29, 2020 at 09:42:59AM -0500, Bryan Steele wrote:
> On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> > Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> > 
> > Machine is a Wyse C90 - orignially sold as a "thin client" - tiny machine, 
> > no serial port (ps and trace typed in).
> > HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> > Was planning to use it as a wifi bridge, so tiny is fine.
> > 
> > "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> > cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> > 06-0d-00
> > RAM: 1GB (despite reported as 3/4 of that)
> 
> Long shot, but could you maybe show the output of "machine memory" for
> both boot/pxeboot? I'm curious if the memory map is reportedly
> differently between a working boot and a bad one.


Good suggestion, and indeed, it differs a little:

Using pxeboot:

CLIENT MAC ADDR: 00 80 64 xx xx xx GUID: C2020018-0403-0920-EE9A-0080648793AD
CLIENT IP: 192.168.42.245 MASK: 255.255.255.0 DHCP IP: 192.168.42.254
GATEWAY IP: 192.168.42.254
probing: pc0 pci pxe![2.1] mem[546K 765M a20-on]
disk: hd0+
net: nac 00:80:64:xx:xx:xx, ip 192.168.42.245, server 192.168.42.254
>> OpenBSD, i386 PXEBOOT 3.43 boot> machine mem
Region 0: type 1 at 0x0 for 546KB
Region 1: type 2 at 0x88800 for 94KB
Region 2: type 2 at Oxe for 128KB
Region 3: type 1 at 0x10 for 784192KB
Region 4: type 3 at Ox2fed for 28KB
Region 5: type 4 at 0x2fed7000 for 4KB
Region 6: type 2 at Ox2fed8000 for 160KB
Region 7: type 2 at Ox2ff0 for 1024KB
Region 8: type 2 at Ox3000 for 262144KB
Region 9: type 2 at Oxe000 for 262144KB
Region 10: type 2 at Oxfec0 for 64KB
Region 11: type 2 at Oxfee0 for 4KB
Region 12: type 2 at Oxfff0 for 1024KB
Low ram: 546KB High ram: 784192KB Total free nemory: 784738KB
boot>
 
Using /boot:

>> OpenBSD/i386 BOOT 3.44
boot> machine mem
Region 0: Type 1 at 0x0x for 631KB
Region 1: Type 2 at 0x9dc99 for 9KB
Region 2: type 2 at 0xe for 128kb
(remainder the same)

Could Region 1 being so microscopic cause problems? If it got used for anything?

Thx for looking.

> > Full dmesg below; full ACPI attached.
> > 
> > Boot used   Kernel  FromResult
> > pxeboot bsd.rd  tftpOK
> > pxeboot bsd hd0aOK (via 
> > tftpboot/etc/conf)
> > bootbsd hd0a    panic
> > 
> > I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> > kernel off same disk via /boot causes panic.
> > 
> > It's an older machine so it's likely a buggy acpi, not worth massive 
> > investment of time, just wonder if there's an easy workaround.
> > Presume it's getting something different in some AML, based on where boot 
> > code loaded from,
> > or else pxeboot vs boot setting environment slightly differently?
> > 
> > On screen after panic:
> > 
> > bios0: WYSE C CLASS
> > acpi0 at bios0: ACPI 3.0
> > acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> > Stopped at db_enter+0x4: popl %eb
> > 
> > trace:
> > 
> > db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> > panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> > pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> > acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> > aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> > aml_opreg_pcicfg_handler+0x21
> > aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> > aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> > aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> > aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> > aml_parse(d2b40704,69,38) at aml_parse+0x351
> > aml_parse(d2b40704,54,9,d2b36518,d2b40704) at aml_parse+0x351
> > aml_eval(0,d2b36544,74,0,0) at aml_eval+0x277
> > aml_evalnode(d10f6b10,d2b36504,0,0,d10f6ac0) at aml_evalnode+0xae
> > aml_evalinteger(d1b1b400,d2b36a84,d0c17e38,0,0,d10f6b30) at 
> > aml_evalinteger+0xae
> > acpi_foundprw(d2b36d04,d2b1b400) at acpi_foundprw+0x2f
> > aml_find_node(d2b36a84,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x?2
> > aml_find_node(d2b336c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> > aml_find_node(d2b296c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> > aml_find_node(d2b31484,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> > aml_find_node(d0eba1a8,d0b9299b,d0859b90,d2b1b400) at aml_find_node+0x9b
> > acpi_init_gpes (d2b1b400) at acpi_init_gpes+0x195 
> > acpi_attach_common(d

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Bryan Steele]

On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> 
> Machine is a Wyse C90 - orignially sold as a "thin client" - tiny machine, no 
> serial port (ps and trace typed in).
> HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> Was planning to use it as a wifi bridge, so tiny is fine.
> 
> "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> 06-0d-00
> RAM: 1GB (despite reported as 3/4 of that)

Long shot, but could you maybe show the output of "machine memory" for
both boot/pxeboot? I'm curious if the memory map is reportedly
differently between a working boot and a bad one.

-Bryan.

> Full dmesg below; full ACPI attached.
> 
> Boot used Kernel  FromResult
> pxeboot   bsd.rd  tftpOK
> pxeboot   bsd hd0aOK (via 
> tftpboot/etc/conf)
> boot  bsd hd0apanic
> 
> I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> kernel off same disk via /boot causes panic.
> 
> It's an older machine so it's likely a buggy acpi, not worth massive 
> investment of time, just wonder if there's an easy workaround.
> Presume it's getting something different in some AML, based on where boot 
> code loaded from,
> or else pxeboot vs boot setting environment slightly differently?
> 
> On screen after panic:
> 
> bios0: WYSE C CLASS
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> Stopped at db_enter+0x4: popl %eb
> 
> trace:
> 
> db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> aml_opreg_pcicfg_handler+0x21
> aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> aml_parse(d2b40704,69,38) at aml_parse+0x351
> aml_parse(d2b40704,54,9,d2b36518,d2b40704) at aml_parse+0x351
> aml_eval(0,d2b36544,74,0,0) at aml_eval+0x277
> aml_evalnode(d10f6b10,d2b36504,0,0,d10f6ac0) at aml_evalnode+0xae
> aml_evalinteger(d1b1b400,d2b36a84,d0c17e38,0,0,d10f6b30) at 
> aml_evalinteger+0xae
> acpi_foundprw(d2b36d04,d2b1b400) at acpi_foundprw+0x2f
> aml_find_node(d2b36a84,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x?2
> aml_find_node(d2b336c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d2b296c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d2b31484,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d0eba1a8,d0b9299b,d0859b90,d2b1b400) at aml_find_node+0x9b
> acpi_init_gpes (d2b1b400) at acpi_init_gpes+0x195 
> acpi_attach_common(d2b1b400,f67a0) at acpi_attach_common+0x355
> acpi_attach(d2b210c0,d2b1b400,d10f6db8) at acpi_attach+0xZc
> config attach(d2b210c0,d0df60d4,d10f6db8,d0928b30) at config attach+0x18a
> config_found_sm(d2b210c0,d10f6db8,d0928630,0) at config_found_sm+0x29
> biosattach(d2b21080, d2b210c0,d10f6eb8) at biosattach+0x19a
> config attach (d2b21080, d0df 4c94,d10f6eb8, d02431f0) at config_attach+0x18a 
> config_found_sm(dZbZ1080, d10f beb8, d02431f0,0) at config_found_sm+0x29 
> mainbus_attach(0,d2b21080,0) at mainbus attach_0x5c
> config_attach(0,d0df 2614,0,0) at config_attach+0x18a
> cpu_configure(lie340b7,10f 4000, 1103000, 10 7000,0) at cpu_configure+0x24 
> main(0,0,0,0,0) at main+0x311
> ddb>
> 
> ps:
>TID   PID  UID  PRFLAGS  PFLAGS  CPU  COMMAND
> *0 00  0x1  0x200 0  swapper
> 
> Dmesg:
> ssh wyse cat /var/run/dmesg.boot
> OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 803459072 (766MB)
> avail mem = 772513792 (736MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 01/16/12, BIOS32 rev. 0 @ 0xfdd30, SMBIOS rev. 2.6 @ 
> 0x2fed8000 (48 entries)
> bios0: vendor Phoenix Technologies version "1.0G" date 01/16/2012
> bios0: WYSE C CLASS
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC MCFG HPET
> acpi0: wakeup devices PWRB(S4) PCI0(S5) PS2M(S3) PS2K(S3) USB1(S4) USB2(S4) 
> USB3(S4) USB4(S4) USB5(S4) HDAC(S5) SP2P(

i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Ian Darwin]

Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020

Machine is a Wyse C90 - orignially sold as a "thin client" - tiny machine, no 
serial port (ps and trace typed in).
HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
Was planning to use it as a wifi bridge, so tiny is fine.

"Latest" BIOS (2012 edition). "BIOS reset" did not help.
cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
06-0d-00
RAM: 1GB (despite reported as 3/4 of that)

Full dmesg below; full ACPI attached.

Boot used   Kernel  FromResult
pxeboot bsd.rd  tftpOK
pxeboot bsd hd0aOK (via tftpboot/etc/conf)
bootbsd hd0apanic

I.e., Boots fine with pxeboot "set device hd0a", but booting exact same kernel 
off same disk via /boot causes panic.

It's an older machine so it's likely a buggy acpi, not worth massive investment 
of time, just wonder if there's an easy workaround.
Presume it's getting something different in some AML, based on where boot code 
loaded from,
or else pxeboot vs boot setting environment slightly differently?

On screen after panic:

bios0: WYSE C CLASS
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
Stopped at db_enter+0x4: popl %eb

trace:

db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
pci_make_tag(0,0,11,0) at pci_make_tag+0x95
acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at aml_opreg_pcicfg_handler+0x21
aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
aml_parse(d2b40704,69,38) at aml_parse+0x351
aml_parse(d2b40704,54,9,d2b36518,d2b40704) at aml_parse+0x351
aml_eval(0,d2b36544,74,0,0) at aml_eval+0x277
aml_evalnode(d10f6b10,d2b36504,0,0,d10f6ac0) at aml_evalnode+0xae
aml_evalinteger(d1b1b400,d2b36a84,d0c17e38,0,0,d10f6b30) at aml_evalinteger+0xae
acpi_foundprw(d2b36d04,d2b1b400) at acpi_foundprw+0x2f
aml_find_node(d2b36a84,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x?2
aml_find_node(d2b336c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
aml_find_node(d2b296c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
aml_find_node(d2b31484,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
aml_find_node(d0eba1a8,d0b9299b,d0859b90,d2b1b400) at aml_find_node+0x9b
acpi_init_gpes (d2b1b400) at acpi_init_gpes+0x195 
acpi_attach_common(d2b1b400,f67a0) at acpi_attach_common+0x355
acpi_attach(d2b210c0,d2b1b400,d10f6db8) at acpi_attach+0xZc
config attach(d2b210c0,d0df60d4,d10f6db8,d0928b30) at config attach+0x18a
config_found_sm(d2b210c0,d10f6db8,d0928630,0) at config_found_sm+0x29
biosattach(d2b21080, d2b210c0,d10f6eb8) at biosattach+0x19a
config attach (d2b21080, d0df 4c94,d10f6eb8, d02431f0) at config_attach+0x18a 
config_found_sm(dZbZ1080, d10f beb8, d02431f0,0) at config_found_sm+0x29 
mainbus_attach(0,d2b21080,0) at mainbus attach_0x5c
config_attach(0,d0df 2614,0,0) at config_attach+0x18a
cpu_configure(lie340b7,10f 4000, 1103000, 10 7000,0) at cpu_configure+0x24 
main(0,0,0,0,0) at main+0x311
ddb>

ps:
   TID   PID  UID  PRFLAGS  PFLAGS  CPU  COMMAND
*0 00  0x1  0x200 0  swapper

Dmesg:
ssh wyse cat /var/run/dmesg.boot
OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 803459072 (766MB)
avail mem = 772513792 (736MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 01/16/12, BIOS32 rev. 0 @ 0xfdd30, SMBIOS rev. 2.6 @ 
0x2fed8000 (48 entries)
bios0: vendor Phoenix Technologies version "1.0G" date 01/16/2012
bios0: WYSE C CLASS
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC MCFG HPET
acpi0: wakeup devices PWRB(S4) PCI0(S5) PS2M(S3) PS2K(S3) USB1(S4) USB2(S4) 
USB3(S4) USB4(S4) USB5(S4) HDAC(S5) SP2P(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 06-0d-00
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,SSE3,EST,TM2,xTPR,NXE
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
cpu0: apic clock running at 100MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 3, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-0
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (SP2P)
acpibtn0 at acpi0: PWRB
"PNP0A03" at acpi0 n

Re: OT acpi failure

[Bodie]

On 8.12.2020 14:35, tru...@tutanota.com wrote:

hallo list,

my machine had one of the ahci failures after which it very fast went
stiff (just the caps and num locks did light on/off if appropriate keys
got pressed).  "very fast" means like a half a minute during which i
managed to switch to ttyC0 to see this "one of the ahci failure"
messages that i suspect come from the kernel(?):

$ doas strings /bsd | fgrep ahci | tail -3
%s: ahci_pmp_probe_timeout: failed to clear active cmds: %08x
ahci
%s: ahci_pmp_probe_timeout: ccb in bad state %d

yes, i panicked enough not to take down the message and whether it was
the first or the third one of the three showed above (it definitely 
read
"ahci0:" at the front of it and "31" at the very end of it) i'm not 
that
concerned about because the sole question i have to you Gurus is if 
this
is a dying motherboard or a dying hard disk (the boot one, the other 
two

are data)

i dare to ask because duckduckgoing from my corner of the web reveals
99% M$ noise with the remaining 1% even more nonsense.

in the meantime i repluged the disk (with the same cable) to another
sata port and i'm hoping to luckily survive till someone knowledgeable
returns with the answer so i know what to mock Mr S.C. for.
/tru



It comes from here 
https://cvsweb.openbsd.org/src/sys/dev/ic/ahci.c?rev=1.37=text/x-cvsweb-markup


Which points do default response in code on timeout, but why that 
timeout


You can enable AHCI_DEBUG in here 
https://cvsweb.openbsd.org/src/sys/dev/ic/ahcivar.h?rev=1.10=text/x-cvsweb-markup


Maybe it will show more details in dmesg then

Besides that you have latest BIOS for this MB, you can try read SMART 
log with atactl(8)




OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
    
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 3991404544 (3806MB)
avail mem = 3857817600 (3679MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (52 entries)
bios0: vendor American Megatrends Inc. version "1701" date 11/18/2016
bios0: ASUSTeK Computer INC. M5A78L-M LX V2
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) RLAN(S4) PCE5(S4)
PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4)
PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD FX(tm)-4170 Quad-Core Processor, 4219.57 MHz, 15-01-02
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully 
associative
cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully 
associative

cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD FX(tm)-4170 Quad-Core Processor, 4218.96 MHz, 15-01-02
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully 
associative
cpu1: DTLB 32 4KB entries fully associative, 32 4MB entries fully 
associative

cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD FX(tm)-4170 Quad-Core Processor, 4218.97 MHz, 15-01-02
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully 
associative
cpu2: DTLB 32 4KB entries fully associative, 32 4MB entries fully 
associative

cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD FX(tm)-4170 Quad-Core Processor, 

FWD: OT its ahci not acpi failure of course

[trubak]

Date: 8 Dec 2020, 14:35
From: tru...@tutanota.com
To: misc@openbsd.org
Subject: OT acpi failure


> hallo list,
>
> my machine had one of the ahci failures after which it very fast went
> stiff (just the caps and num locks did light on/off if appropriate keys
> got pressed).  "very fast" means like a half a minute during which i
> managed to switch to ttyC0 to see this "one of the ahci failure"
> messages that i suspect come from the kernel(?):
>
> $ doas strings /bsd | fgrep ahci | tail -3
> %s: ahci_pmp_probe_timeout: failed to clear active cmds: %08x
> ahci
> %s: ahci_pmp_probe_timeout: ccb in bad state %d
>
> yes, i panicked enough not to take down the message and whether it was
> the first or the third one of the three showed above (it definitely read
> "ahci0:" at the front of it and "31" at the very end of it) i'm not that
> concerned about because the sole question i have to you Gurus is if this
> is a dying motherboard or a dying hard disk (the boot one, the other two
> are data)
>
> i dare to ask because duckduckgoing from my corner of the web reveals
> 99% M$ noise with the remaining 1% even more nonsense.
>
> in the meantime i repluged the disk (with the same cable) to another
> sata port and i'm hoping to luckily survive till someone knowledgeable
> returns with the answer so i know what to mock Mr S.C. for.
> /tru
>
>
> OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
>     > dera...@amd64.openbsd.org> :/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3991404544 (3806MB)
> avail mem = 3857817600 (3679MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (52 entries)
> bios0: vendor American Megatrends Inc. version "1701" date 11/18/2016
> bios0: ASUSTeK Computer INC. M5A78L-M LX V2
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
> acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) RLAN(S4) PCE5(S4) PCE6(S4) 
> PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2K(S4) UAR1(S4) 
> P0PC(S4) UHC1(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 16 (boot processor)
> cpu0: AMD FX(tm)-4170 Quad-Core Processor, 4219.57 MHz, 15-01-02
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
> cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
> 16-way L2 cache, 8MB 64b/line 64-way L3 cache
> cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
> cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 200MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 17 (application processor)
> cpu1: AMD FX(tm)-4170 Quad-Core Processor, 4218.96 MHz, 15-01-02
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
> cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
> 16-way L2 cache, 8MB 64b/line 64-way L3 cache
> cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
> cpu1: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 18 (application processor)
> cpu2: AMD FX(tm)-4170 Quad-Core Processor, 4218.97 MHz, 15-01-02
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
> cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
> 16-way L2 cache, 8MB 64b/line 64-way L3 cache
> cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
> cpu2: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 19 (application processor)
> cpu3: AMD FX(tm)-4170 Quad-Core Processor, 4218.

OT acpi failure

[trubak]

hallo list,

my machine had one of the ahci failures after which it very fast went
stiff (just the caps and num locks did light on/off if appropriate keys
got pressed).  "very fast" means like a half a minute during which i
managed to switch to ttyC0 to see this "one of the ahci failure"
messages that i suspect come from the kernel(?):

$ doas strings /bsd | fgrep ahci | tail -3
%s: ahci_pmp_probe_timeout: failed to clear active cmds: %08x
ahci
%s: ahci_pmp_probe_timeout: ccb in bad state %d

yes, i panicked enough not to take down the message and whether it was
the first or the third one of the three showed above (it definitely read
"ahci0:" at the front of it and "31" at the very end of it) i'm not that
concerned about because the sole question i have to you Gurus is if this
is a dying motherboard or a dying hard disk (the boot one, the other two
are data)

i dare to ask because duckduckgoing from my corner of the web reveals
99% M$ noise with the remaining 1% even more nonsense.

in the meantime i repluged the disk (with the same cable) to another
sata port and i'm hoping to luckily survive till someone knowledgeable
returns with the answer so i know what to mock Mr S.C. for.
/tru


OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
    dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3991404544 (3806MB)
avail mem = 3857817600 (3679MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (52 entries)
bios0: vendor American Megatrends Inc. version "1701" date 11/18/2016
bios0: ASUSTeK Computer INC. M5A78L-M LX V2
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) RLAN(S4) PCE5(S4) PCE6(S4) 
PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2K(S4) UAR1(S4) 
P0PC(S4) UHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD FX(tm)-4170 Quad-Core Processor, 4219.57 MHz, 15-01-02
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD FX(tm)-4170 Quad-Core Processor, 4218.96 MHz, 15-01-02
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD FX(tm)-4170 Quad-Core Processor, 4218.97 MHz, 15-01-02
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu2: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD FX(tm)-4170 Quad-Core Processor, 4218.96 MHz, 15-01-02
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,CPCTR,ITSC
cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 
16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu3: ITLB 48 4KB entries fully associati

Lenovo T590 ACPI issues with current + Thunderbolt 3 support?

[Bodie]

Hi all,

error related to ACPI follows after dmesg. I can provide pcidump, 
usbdevs or acpidump too if needed.
In general machine seems to be working fine (booted from USB flash in 
USB 3.1 port). WiFi and LAN

works great in trunk setup, 3D on Intel VGA and X11 works.

dmesg and sensors send as well to dmesg@

I am expecting that some of the devices will not work (like Bluetooth 
obviously) or may not be needed

at all like Intel MEI

I have spare NVMe disk Intel SSDPEKKF512G8L , 2280 and was thinking to 
put it in some supported
USB 3.1 external box, install OpenBSD on it and use it as sort of 
dualboot (Windows must stay for

now however :-)).

BUT reading xhci(4) and looking via misc@ archives it seems like USB 3.1 
Gen1/Gen2 is not yet supported

and thus I will not be able to use Thunderbolt 3 port with 40Gb/s speed.

As power is available only via those 2 it may be then related to that 
ACPI issue with AC adapter.

( just wild guess now )

OpenBSD 6.8-current (GENERIC.MP) #202: Mon Nov 30 13:05:12 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 33465077760 (31914MB)
avail mem = 32435552256 (30932MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x600f6000 (67 entries)
bios0: vendor LENOVO version "N2IET92W (1.70 )" date 09/21/2020
bios0: LENOVO 20N5S4DA01
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET 
APIC MCFG ECDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM 
BATB DMAR NHLT ASF!

 FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) 
PXSX(S4) RP06(S4) P

XSX(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-8665U CPU @ 1.90GHz, 1794.44 MHz, 06-8e-0c
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,V

MX,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,3DNOW
P,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,AR
AT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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-8665U CPU @ 1.90GHz, 1794.87 MHz, 06-8e-0c
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,V

MX,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,3DNOW
P,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,AR
AT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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-8665U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0c
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,V

MX,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,3DNOW
P,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,AR
AT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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-8665U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0c
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,V

MX,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,3DNOW
P,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,AR
AT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-8665U CPU @ 1.90GH

OBSD 6.8 boot hang on azalia, acpi vs msi issue?

[Mike Williams]

Hi,

I updated a box with a VIA VE-900 chipset (VIA Nano X2 CPU) from 6.7 to 
6.8 which then hung during first boot with 6.8.  The last line was for 
azalia.  I rebooted and disabled azalia which allowed the 6.8 boot to 
complete.


Comparing the dmesg with that from 6.7 showed that the change was from 
using acpi to msi for the device.  Also that the on board NIC is no 
longer seen under 6.8.  The re device is seen by find but doesn't appear 
from the boot process, either taken out by disabling azalia or a 
separate problem.  (I stuck a usb wifi dongle on the box to finish the 
upgrade process.)


Here is the diff between the two dmesgs:

-- *** ../dmesg/dmesg6.7Sat May 30 09:05:59 2020
--- dmesg6.8-noazalia   Sat Oct 24 18:01:12 2020
***
*** 39,51 
  acpiprt1 at acpi0: bus 1 (NBP0)
  acpiprt2 at acpi0: bus 5 (NBP3)
  acpiprt3 at acpi0: bus 6 (P0P4)
! acpicpu0 at acpi0: C1(1000@1 halt), PSS
! acpicpu1 at acpi0: C1(1000@1 halt), PSS
! acpipci0 at acpi0 PCI0: _OSC failed
  acpiac0 at acpi0: AC unit online
  acpicmos0 at acpi0
  acpibtn0 at acpi0: SLPB
  acpibtn1 at acpi0: PWRB
  acpivideo0 at acpi0: VUMA
  acpivout0 at acpivideo0: LCD_
  cpu0: Enhanced SpeedStep 1400 MHz: speeds: 1400, 1200, 1100, 1000, 
900, 800 MHz

--- 47,59 
  acpiprt1 at acpi0: bus 1 (NBP0)
  acpiprt2 at acpi0: bus 5 (NBP3)
  acpiprt3 at acpi0: bus 6 (P0P4)
! acpipci0 at acpi0 PCI0
  acpiac0 at acpi0: AC unit online
  acpicmos0 at acpi0
  acpibtn0 at acpi0: SLPB
  acpibtn1 at acpi0: PWRB
+ acpicpu0 at acpi0: C1(1000@1 halt), PSS
+ acpicpu1 at acpi0: C1(1000@1 halt), PSS
  acpivideo0 at acpi0: VUMA
  acpivout0 at acpivideo0: LCD_
  cpu0: Enhanced SpeedStep 1400 MHz: speeds: 1400, 1200, 1100, 1000, 
900, 800 MHz

***
*** 61,78 
  vga1 at pci0 dev 1 function 0 "VIA Chrome9 HD" rev 0x00
  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
  wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
! azalia0 at pci0 dev 1 function 1 "VIA HD Audio" rev 0x00: apic 4 int 17
! azalia0: no supported codecs
! ppb0 at pci0 dev 3 function 0 "VIA VX900 PCIE" rev 0x00: apic 4 int 3
  pci1 at ppb0 bus 1
! ppb1 at pci0 dev 3 function 1 "VIA VX900 PCIE" rev 0x00: apic 4 int 7
  pci2 at ppb1 bus 2
! ppb2 at pci0 dev 3 function 2 "VIA VX900 PCIE" rev 0x00: apic 4 int 11
  pci3 at ppb2 bus 3
! ppb3 at pci0 dev 3 function 3 "VIA VX900 PCIE" rev 0x00: apic 4 int 15
  pci4 at ppb3 bus 5
- re0 at pci4 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E 
(0x2c00), apic 4 int 12, address c8:9c:dc:54:5f:77

- rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
  pchb8 at pci0 dev 3 function 4 "VIA VX900 PCIE" rev 0x00
  pciide0 at pci0 dev 15 function 0 "VIA VX900 IDE" rev 0x00: ATA133, 
channel 0 configured to native-PCI, channel 1 configured to native-PCI

  pciide0: using apic 3 int 21 for native-PCI interrupt
--- 69,83 
  vga1 at pci0 dev 1 function 0 "VIA Chrome9 HD" rev 0x00
  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
  wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
! "VIA HD Audio" rev 0x00 at pci0 dev 1 function 1 not configured
! ppb0 at pci0 dev 3 function 0 "VIA VX900 PCIE" rev 0x00: msi
  pci1 at ppb0 bus 1
! ppb1 at pci0 dev 3 function 1 "VIA VX900 PCIE" rev 0x00: msi
  pci2 at ppb1 bus 2
! ppb2 at pci0 dev 3 function 2 "VIA VX900 PCIE" rev 0x00: msi
  pci3 at ppb2 bus 3
! ppb3 at pci0 dev 3 function 3 "VIA VX900 PCIE" rev 0x00: msi
  pci4 at ppb3 bus 5
  pchb8 at pci0 dev 3 function 4 "VIA VX900 PCIE" rev 0x00
  pciide0 at pci0 dev 15 function 0 "VIA VX900 IDE" rev 0x00: ATA133, 
channel 0 configured to native-PCI, channel 1 configured to native-PCI

  pciide0: using apic 3 int 21 for native-PCI interrupt
***
*** 92,100 
  pchb9 at pci0 dev 17 function 7 "VIA VX800 Host" rev 0x00
  ppb4 at pci0 dev 19 function 0 "VIA VX800" rev 0x00
  pci5 at ppb4 bus 6
! azalia1 at pci0 dev 20 function 0 "VIA HD Audio" rev 0x20: apic 3 int 17
! azalia1: codecs: VIA/0x0397
! audio0 at azalia1
  usb1 at uhci0: USB revision 1.0
  uhub1 at usb1 configuration 1 interface 0 "VIA UHCI root hub" rev 
1.00/1.00 addr 1

  usb2 at uhci1: USB revision 1.0
--- 97,103 
  pchb9 at pci0 dev 17 function 7 "VIA VX800 Host" rev 0x00
  ppb4 at pci0 dev 19 function 0 "VIA VX800" rev 0x00
  pci5 at ppb4 bus 6
! "VIA HD Audio" rev 0x20 at pci0 dev 20 function 0 not configured
  usb1 at uhci0: USB revision 1.0
  uhub1 at usb1 configuration 1 interface 0 "VIA UHCI root hub" rev 
1.00/1.00 addr 1

  usb2 at uhci1: USB revision 1.0

I have been running OBSD since 5.1 on this box without problem. 
Checking back through the dmesgs this is the first time msi has been 
used instead of acpi.


Is the issue switching to use msi, or not using acpi as

Re: Disabling ACPI permanently

[Radek]

Hello Philip,

This box has installed the newest BIOS firmware. 

Following your suggestion I sent a bug report to b...@openbsd.org
https://marc.info/?l=openbsd-bugs=157747038309405=2


On Mon, 23 Dec 2019 08:25:13 -0800
Philip Guenther  wrote:

> On Mon, Dec 23, 2019 at 5:10 AM Radek  wrote:
> 
> > I'm trying to permanently disable acpi doing the following steps[1].
> > After the first reboot OS boots fine.
> > After the second reboot acpi seems to be re-enabled at boot - I get [2].
> > What Am I doing wrong?
> >
> 
> First, you should also check whether there's a newer BIOS firmware for this
> box, as there's a good chance Intel has fixed issues and issued a new one.
> If so, installing that may totally resolve the issue.
> 
> If not, or if upgrading the firmware doesn't resolve this, then you should
> next send a bug report to b...@openbsd.org using sendbug.  To get the most
> data when you do so, disable _just_ the acpipci device (using boot -c)
> instead of all of acpi and then run sendbug as root on that system.  The
> bug report will then include the data from the ACPI tables, so that the
> driver can be fixed to deal with this.
> 
> ...
> 
> > acpipci0 at acpi0 PCI0panic: malloc: allocation too large, type = 33, size
> > = 292057776136
> >
> 
> 
> Philip Guenther


-- 
Radek

Re: Disabling ACPI permanently

[Philip Guenther]

On Mon, Dec 23, 2019 at 5:10 AM Radek  wrote:

> I'm trying to permanently disable acpi doing the following steps[1].
> After the first reboot OS boots fine.
> After the second reboot acpi seems to be re-enabled at boot - I get [2].
> What Am I doing wrong?
>

First, you should also check whether there's a newer BIOS firmware for this
box, as there's a good chance Intel has fixed issues and issued a new one.
If so, installing that may totally resolve the issue.

If not, or if upgrading the firmware doesn't resolve this, then you should
next send a bug report to b...@openbsd.org using sendbug.  To get the most
data when you do so, disable _just_ the acpipci device (using boot -c)
instead of all of acpi and then run sendbug as root on that system.  The
bug report will then include the data from the ACPI tables, so that the
driver can be fixed to deal with this.

...

> acpipci0 at acpi0 PCI0panic: malloc: allocation too large, type = 33, size
> = 292057776136
>


Philip Guenther

Disabling ACPI permanently

[Radek]

Hello,
I'm trying to permanently disable acpi doing the following steps[1].
After the first reboot OS boots fine.
After the second reboot acpi seems to be re-enabled at boot - I get [2].
What Am I doing wrong?

[1]
boot -c
UKC>disable acpi
444 acpi0 disabled
UKC>quit
Continuing...
[...]
mv /bsd /bsd.old
config -e -o /bsd /bsd.old
OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 01:58:46 MST 2019
r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Enter 'help' for information
ukc> disable acpi
444 acpi0 disabled
ukc> quit
Saving modified kernel.

[2]
OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 01:58:46 MST 2019
r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1047724032 (999MB)
avail mem = 1003417600 (956MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfcd70 (77 entries)
bios0: vendor Intel Corp. version "BA72210A.86B.0228.2005.1122.2349" date 
11/22/2005
bios0: MAXDATA PLATINUM 100 I M5
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG ASF! WDDT
acpi0: wakeup devices PEGP(S4) P0P2(S4) AC97(S4) USB0(S1) USB1(S1) USB2(S1) 
USB3(S1) USB7(S1) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) AZAL(S4) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 3.06GHz, 3067.28 MHz, 0f-04-09
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,DTES64,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG,LAHF,MELTDOWN
cpu0: 256KB 64b/line 4-way L2 cache
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEGP)
acpiprt2 at acpi0: bus 6 (P0P2)
acpiprt3 at acpi0: bus 5 (PEX1)
acpiprt4 at acpi0: bus 4 (PEX2)
acpiprt5 at acpi0: bus 3 (PEX3)
acpicpu0 at acpi0: C1(@1 halt!)
acpipwrres0 at acpi0: URP1
acpipwrres1 at acpi0: FDDP
acpipwrres2 at acpi0: LPTP
acpipwrres3 at acpi0: URP2
acpipci0 at acpi0 PCI0panic: malloc: allocation too large, type = 33, size = 
292057776136

Stopped at  db_enter+0x10:  popq%rbp
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
* 0  0  0 0x1  0x2000  swapper
db_enter(10,82281280,202,8,812c2e00,82281280) at db_ent
er+0x10
panic(81c2af40,81c2af40,8007a088,21,0,440008) at pa
nic+0x128
malloc(440008,21,9,440008,8642e84c095b2331,8007a088) at malloc+
0x6d9
aml_parse(8007a088,74,0,8007a088,e233b61729a271c4,8007a
088) at aml_parse+0x1734
aml_parse(8007a088,54,c,8007a088,e233b61729a286b7,8007a
088) at aml_parse+0x54c
aml_eval(0,80072608,74,82281700,82281700,0) at aml_eval
+0x33f
aml_evalnode(800725ac,80072588,4,82281700,82281
820,800725ac) at aml_evalnode+0xb5
acpipci_attach(80021400,80079d80,82281970,80021
400,f736340b0bc20316,80021400) at acpipci_attach+0xf7
config_attach(80021400,81f06328,82281970,81aa8a
50,472b3934561bab9a,80041708) at config_attach+0x1ee
acpi_foundhid(80041708,80021400,c02f249ab5605f64,81aabc
c0,80021400,80041188) at acpi_foundhid+0x2dc
aml_find_node(80041188,81c413d0,81aabcc0,800214
00,c1874c1cd841fb5c,81aabcc0) at aml_find_node+0x84
aml_find_node(80023a88,81c413d0,81aabcc0,800214
00,c1874c1cd841fb5c,81aabcc0) at aml_find_node+0xb1
aml_find_node(81f90200,81c413d0,81aabcc0,800214
00,c1874c1cd8e35490,82281b50) at aml_find_node+0xb1
acpi_attach_common(80021400,f5600,f55897af781bc332,80023180,fff
f82281c58,81f31230) at acpi_attach_common+0x7ad
end trace frame: 0x82281c40, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb>

-- 
Radek

acpi interrupt storm on HP EliteBook 840 G1

[Greg Steuck]

I have a Hewlett-Packard HP EliteBook 840 G1 amd64 machine exhibiting
strange bouts of acpi0 interrupt storms. Depending on some
undetermined factor after a reboot the machine may come up with acpi0
interrupts firing 5k times per second. This boggles the machine
down. There's a sure fire way to avoid the problem by disabling acpi
in UKC. Naturally this makes the machine unable to sleep. I tried to
collect some obvious things, but happy to produce more upon request.

The contents of
   cp -R /var/db/acpi /tmp && iasl -d /tmp/acpi/*
are here: https://blackgnezdo.github.io/hp-elitebook-840.tgz

systat views:

2 users Load 1.31 1.49 1.40   hippy.nest.cx 10:13:13

memory totals (in KB)PAGING   SWAPPING Interrupts
   real   virtual free   in  out   in  out 5128 total
Active   426904426904 14395076   ops100 clock
All 1751896   1751896 31016684   pages  ipi
   5016 acpi0
Proc:r  d  s  wCsw   Trp   Sys   Int   Sof  Flt   forks inteldrm
 2   152 10051  1103   142  5027  1051   79   fkppw xhci0
  fksvm   1 em0
  18.6%Int   0.3%Spn   3.6%Sys   0.1%Usr  77.3%Idle   pwait azalia1
|||||||||||   relck  11 iwm0
|==   rlkok ehci0
  noram ahci0
Namei Sys-cacheProc-cacheNo-cache  19 ndcpy pckbc0
Calls hits%hits %miss   %   2 fltcp pckbc0
  101  101  10011 zfod
1 cow
Disks   sd0134558 fmin
seeks  179410 ftarg
xfers 1   itarg
speed   13K 12145 wired
  sec   0.0   pdfre
  pdscn   1 IPKTS
  pzidl   1 OPKTS

   2 users Load 1.38 1.48 1.40   hippy.nest.cx 10:14:29

 PID USERNAME CPU  20\ 40\
60\ 80\   100\
  74.80

   20461 rootacpi0  14.79 #
   56548 _x11Xorg   12.55 
   58356 gregchrome  3.27 #
   11548 gregemacs-26.3  2.64
   59152 gregxmobar  2.10
   48669 gregxmonad-x86_64-op2.05
   92413 gregxterm   1.42

dmesg:

OpenBSD 6.6 (GENERIC.MP) #370: Fri Oct 11 13:32:44 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17055608832 (16265MB)
avail mem = 16526012416 (15760MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbbe3f000 (33 entries)
bios0: vendor Hewlett-Packard version "L71 Ver. 01.20" date 07/28/2014
bios0: Hewlett-Packard HP EliteBook 840 G1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SSDT FPDT BGRT SSDT
SSDT SSDT SSDT SSDT ASF! DMAR
acpi0: wakeup devices LANC(S5) EHC1(S3) XHC_(S3) PCIB(S5) NIC_(S5)
RP04(S5) WNIC(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.71 MHz, 06-45-01
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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
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 1 (application processor)
TSC skew=-41
cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 MHz, 06-45-01
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,SS

denverton acpi reboot

[sven falempin]

it works, (did not in 6.4 )

who s the awesome fellow who did that

Thank you

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

APU2/3/4 get ACPI GPIO & IOMMU support

[Noth]

Hi all,

  The PC Engines APU2/3/4 mainline firmware was updated this week and 
they've enabled ACPI GPIO calls as well as IOMMU support. I saw tech@ 
got a patch for apugpio in March, maybe it could be updated to use ACPI?


Link to firmware is here: 
https://pcengines.github.io/?utm_source=PC+Engines+Open+Source+Firmware+Release_campaign=8e5255d4da-EMAIL_CAMPAIGN_2019_05_10_09_20_COPY_01_medium=email_term=0_b9727cda45-8e5255d4da-48008233



Cheers,

Noth

Re: Live ACPI "Hibernate" Style Snapshot possible without Powering Down?

[Mike Larkin]

On Mon, Mar 04, 2019 at 06:44:15PM -0700, Theo de Raadt wrote:
> Z Ero  wrote:
> 
> > Hello,
> > 
> > Curious if there is a facility to save system memory state to disk for
> > recovery such as is done the ZZZ (hibernate) command without actually
> > powering down? Could be useful to return to a previous active memory
> > state for devices that are not on UPS or not closely monitored but do
> > preform non-scripted batch work.
> > 
> > So, for example if there is a transient power interruption on
> > 03-05-2019 at 12 AM the device could be configured just to reboot to
> > the state it was in at 03-04-2019 at 12 AM where it was doing similar
> > work. I don't mean load a file back up but reload a previous active
> > memory / process state as if returning from hibernate.
> > 
> > Thus to enable this hibernate style dumps would be saved periodically
> > by cron for example.
> > 
> > I understand that for some dumping active memory to disk without
> > powering down might present a security concern but this is not a
> > problem for my application.
> 
> What you are asking for is impossible to do correctly, because files
> will be open.  As a result, the filesystem image you return to will be
> incoherent with respect to the open vnodes.
> 
> I mean, it can be done.  It just will have so many artificial deficits
> at the low-level that it won't suit the high-level purpose you intend
> fully.
> 

If one really wanted to do this, the right approach would be to start with
filesystem and memory snapshots in vmm/vmd. I think the former can be done
with enhancing qcow2, and the latter is basically already done (via vmctl
send).

I await OP's diff to implement this.

-ml

Re: Live ACPI "Hibernate" Style Snapshot possible without Powering Down?

[Theo de Raadt]

Z Ero  wrote:

> Hello,
> 
> Curious if there is a facility to save system memory state to disk for
> recovery such as is done the ZZZ (hibernate) command without actually
> powering down? Could be useful to return to a previous active memory
> state for devices that are not on UPS or not closely monitored but do
> preform non-scripted batch work.
> 
> So, for example if there is a transient power interruption on
> 03-05-2019 at 12 AM the device could be configured just to reboot to
> the state it was in at 03-04-2019 at 12 AM where it was doing similar
> work. I don't mean load a file back up but reload a previous active
> memory / process state as if returning from hibernate.
> 
> Thus to enable this hibernate style dumps would be saved periodically
> by cron for example.
> 
> I understand that for some dumping active memory to disk without
> powering down might present a security concern but this is not a
> problem for my application.

What you are asking for is impossible to do correctly, because files
will be open.  As a result, the filesystem image you return to will be
incoherent with respect to the open vnodes.

I mean, it can be done.  It just will have so many artificial deficits
at the low-level that it won't suit the high-level purpose you intend
fully.

Re: Live ACPI "Hibernate" Style Snapshot possible without Powering Down?

[Mike Larkin]

On Mon, Mar 04, 2019 at 07:06:15PM -0500, Z Ero wrote:
> Hello,
> 
> Curious if there is a facility to save system memory state to disk for
> recovery such as is done the ZZZ (hibernate) command without actually
> powering down? Could be useful to return to a previous active memory
> state for devices that are not on UPS or not closely monitored but do
> preform non-scripted batch work.
> 
> So, for example if there is a transient power interruption on
> 03-05-2019 at 12 AM the device could be configured just to reboot to
> the state it was in at 03-04-2019 at 12 AM where it was doing similar
> work. I don't mean load a file back up but reload a previous active
> memory / process state as if returning from hibernate.
> 
> Thus to enable this hibernate style dumps would be saved periodically
> by cron for example.
> 
> I understand that for some dumping active memory to disk without
> powering down might present a security concern but this is not a
> problem for my application.
> 
> Thanks
> 

We don't do this.

Live ACPI "Hibernate" Style Snapshot possible without Powering Down?

[Z Ero]

Hello,

Curious if there is a facility to save system memory state to disk for
recovery such as is done the ZZZ (hibernate) command without actually
powering down? Could be useful to return to a previous active memory
state for devices that are not on UPS or not closely monitored but do
preform non-scripted batch work.

So, for example if there is a transient power interruption on
03-05-2019 at 12 AM the device could be configured just to reboot to
the state it was in at 03-04-2019 at 12 AM where it was doing similar
work. I don't mean load a file back up but reload a previous active
memory / process state as if returning from hibernate.

Thus to enable this hibernate style dumps would be saved periodically
by cron for example.

I understand that for some dumping active memory to disk without
powering down might present a security concern but this is not a
problem for my application.

Thanks

Re: ACPI interrupt storm on ThinkPad T480s

[Matthieu Guegan]

On Tue, May 01, 2018 at 03:37:50AM -0400, Ryan Lennox wrote:


If it's the same bug, you should find something like this block
of code in the file /tmp/acpi/DSDT.dsl
...
   If ((TBTS == 0x01))
   {
   Acquire (OSUM, 0x)
   \_GPE.TINI (TBSE)
   If ((TBMP == 0x01))
   {
   \_GPE.TINI (TBS1)
   }

   Release (OSUM)
   }
...

If this bug affects their flagship device, then hopefully it will be
easier to convince them to fix it.


I have exactly the same block of code with the X1C 6th Gen..

Re: ACPI interrupt storm on ThinkPad T480s

[Ryan Lennox]

On April 26, 2018 2:40 PM, Matthieu Guegan <matth...@guegan.ch> wrote:

> Hi,
> 
> Just want to add the X1 Carbon Gen 6th to the list. Same problem when
> 
> plug in a thunderbolt device.
> 

We should confirm that it's the same bug.

Here's what I did on the T480s:

# pkg_add acpica
$ cp -R /var/db/acpi /tmp
$ iasl -d /tmp/acpi/*

If it's the same bug, you should find something like this block
of code in the file /tmp/acpi/DSDT.dsl
...
If ((TBTS == 0x01))
{
Acquire (OSUM, 0x)
\_GPE.TINI (TBSE)
If ((TBMP == 0x01))
{
\_GPE.TINI (TBS1)
}

Release (OSUM)
}
...

If this bug affects their flagship device, then hopefully it will be
easier to convince them to fix it.

Re: ACPI interrupt storm on ThinkPad T480s

[Matthieu Guegan]

Hi,

Just want to add the X1 Carbon Gen 6th to the list. Same problem when 
plug in a thunderbolt device.


Apart from that, the other thing is that S3 (suspend to ram) mode is not 
supported by the BIOS (it has a special S0i3 mode instead which is 
exclusive with the S3 mode).

ACPI interrupt storm on ThinkPad T480s

[Ryan Lennox]

Hi,

I encountered the same issue on a new T480s as reported here:
https://marc.info/?l=openbsd-bugs=152022260714390=2

I am posting this to misc because the bug appears to be with Lenovo's ACPI 
tables, not OpenBSD. I just wanted to provide some updated information for 
anyone else who has this machine and might be experiencing the same issues.

Lenovo just released another UEFI update:

"<1.12>
 UEFI: 1.12 / ECP: 1.07
- (Fix) Fix an issue where the "Configuration changed - restart the system" 
message might be displayed 2 or 3 times on Non-Smart Card model when power on 
the computer.

<1.11>
 UEFI: 1.11 / ECP: 1.07
- (Fix) Fix an issue where system may become hot by system interrupts when 
Thundrebolt is disabled in ThinkPad Setup - Security - I/O Port Access."

These sound promising because the changelog addresses both issues.

I never encountered the message "configuration changed - restart the system" in 
the first place, so I can't really confirm or deny whether that fix works. 
Ironically, I did see that message for the first time ever - immediately after 
applying the UEFI update that claims to fix it. Thankfully I haven't seen it 
again since.

Unfortunately, the thunderbolt interrupt issue has only been fixed for the 
"disabled" state. With thunderbolt enabled, the ACPI interrupt storm still 
happens as usual. It occurs on every cold-boot, and is always resolved by a 
reboot.

I compared the old and new DSDT tables to see how they modified the thunderbolt 
code. I don't know much about the ASL language, so I can't really comment on 
the specifics of what they've done, but to my untrained eye, and given that it 
doesn't work, it may have been unnecessary.

I have a hunch that the bug is actually in these sections:
...
If ((TBTS == 0x01))
{
Acquire (OSUM, 0x)
\_GPE.TINI (TBSE)
If ((TBMP == 0x01))
{
\_GPE.TINI (TBS1)
}

Release (OSUM)
}
...
If ((TBTS == 0x01))
{
Acquire (OSUM, 0x)
\_GPE.TINI (TBSE)
Release (OSUM)
If ((TBMP == 0x01))
{
Acquire (OSUM, 0x)
\_GPE.TINI (TBS1)
Release (OSUM)
}
...

The first block appears in a "wake" section, and the second block appears in an 
"initialize" section. This fits the problem description; When I cold-boot the 
system, the interrupt problem always exists. When I reboot the system, the 
interrupt problem never exists. Therefore, one of these sections must not be 
acquiring and releasing mutexes properly. I believe the second section is 
correct, and the first section should be rewritten to match (contrary to my 
expectations, this implies a cold-boot is considered to be a "wake" event 
rather than an "initialization" event).

As an aside, I noticed the list of operating systems in the "initialize" 
section is missing OpenBSD. How inconsiderate!
...
If (\_OSI ("Linux"))
{
\LNUX = 0x01
OSYS = 0x03E8
}

If (\_OSI ("FreeBSD"))
{
\LNUX = 0x01
OSYS = 0x03E8
}
...

Solutions, from worst to best:

1) After powering on the machine, type "reboot" at the OpenBSD bootloader.
2) Update to the latest UEFI firmware and then disable thunderbolt.
3) Report the bug to Lenovo so they can investigate and fix it at the source.

Anybody have a contact within Lenovo for option 3?

Regression in sys/dev/acpi/dwiic.c

[Callum R. Davies]

I use an Asus X205TA, which is an irritating system with an I2C HID
keyboard.  As of revision 1.18 of sys/dev/acpi/dwiic.c, I have been
unable to upgrade to the latest snapshots as said keyboard fails to
attach during boot.

The following patch appears to resolve the problem.  Also included is a
dmesg (from an earlier kernel).

Index: sys/dev/acpi/dwiic.c
===
RCS file: /cvs/src/sys/dev/acpi/dwiic.c,v
retrieving revision 1.20
diff -u -p -r1.20 dwiic.c
--- sys/dev/acpi/dwiic.c1 Sep 2016 10:04:51 -   1.20
+++ sys/dev/acpi/dwiic.c7 Sep 2016 09:33:54 -
@@ -1014,9 +1014,6 @@ dwiic_i2c_exec(void *cookie, i2c_op_t op
}
}
 
-   /* disable controller */
-   dwiic_enable(sc, 0);
-
sc->sc_busy = 0;
 
return 0;

OpenBSD 6.0-current (GENERIC.MP) #2353: Sat Aug 13 11:34:33 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 3f<config_unit,memory_size,fixed_disk,invalid_time>
real mem = 2063134720 (1967MB)
avail mem = 1996189696 (1903MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries)
bios0: vendor American Megatrends Inc. version "X205TA.208" date 12/18/2014
bios0: ASUSTeK COMPUTER INC. X205TA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT SSDT 
SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM
acpi0: wakeup devices WLAN(S0) RTLW(S0)
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.57 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiec0 at acpi0: not present
acpicpu0 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpicpu1 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpicpu2 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpicpu3 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1
acpipwrres2 at acpi0: CLK0, resource for CAM1
acpipwrres3 at acpi0: CLK1, resource for CAM0
acpipwrres4 at acpi0: P28X
acpipwrres5 at acpi0: P18X
acpipwrres6 at acpi0: P28P
acpipwrres7 at acpi0: P18P
acpipwrres8 at acpi0: P28T, resource for CAM0, CAM1
acpipwrres9 at acpi0: P18T, resource for CAM0, CAM1
acpipwrres10 at acpi0: P1XT
acpitz0 at acpi0: no critical temperature defined
"INT3396" at acpi0 not configured
"PNP0501" at acpi0 not configured
"80860F28" at acpi0 not configured
"INT0002" at acpi0 not configured
bytgpio0 at acpi0: GPO0 uid 1 addr 0xfed0c000/0x1000 irq 49, 102 pins
bytgpi

Re: Various ACPI problems on various IBM hardware

[Mike Larkin]

On Fri, Aug 14, 2015 at 03:13:17PM +0200, Frederic URBAN wrote:
 Hello,
 
 We have some ACPI problems with various IBM server X. Since it's a very 
 early panic when kernel boot there is now access to ddb to print the 
 trace. You are prompted to press any key to reboot :) It has been 
 verified on IBM Server x3650 M1, M2 and M3. We are using OpenBSD 5.7, 
 this panic happends with bsd.rd and bsd.mp
 
 The system is usable when I disable acpi when booting on RAMDISK_CD and 
 after the installation on GENERIC.MP
 
 I can provide a screenshot of the KVM over LAN if you guys wants. Like 
 we did in the past (Adding support of Intel 82576 on em(4)), I also can 
 provide you a remote access to both oldest machines (a Server x3650 M1 
 and a Server x3650 M2) with serial cable to help you to fix this. We are 
 big users of OpenBSD on various systems (Dell, HP) for the first time i 
 need to install a firewall on IBM hardware so if we can help, i'm ready 
 to setup a lab for you.
 

I'll volunteer to help here. Please send a dmesg and screen capture of
the panic, and acpidump if available.

We can then decide if remote access is needed.

-ml

 Fr??d??ric.
 -- 
 Fr??d??ric URBAN
 *Fr??d??ric URBAN*
 Ing??nieur R??seaux
 
 frederic.ur...@ircad.fr mailto:frederic.ur...@ircad.fr
 T??l. : +33 (0)3 88 119 038
   IRCAD France
 http://www.ircad.fr/ http://www.ircad.fr/
 
 Suivez l'IRCAD sur Facebook 
 http://www.facebook.com/pages/IRCAD/193785273990141
 
 *IRCAD France*
 H??pitaux Universitaires - 1, place de l'H??pital - 67091 Strasbourg Cedex 
 - FRANCE

Re: Various ACPI problems on various IBM hardware

[Alexey Suslikov]

Frederic URBAN frederic.urban at ircad.fr writes:

 We have some ACPI problems with various IBM server X. Since it's a very 
 early panic when kernel boot there is now access to ddb to print the 
 trace. You are prompted to press any key to reboot :) It has been 
 verified on IBM Server x3650 M1, M2 and M3. We are using OpenBSD 5.7, 
 this panic happends with bsd.rd and bsd.mp

You really need to try more -current OpenBSD version. Use a
snapshot for that.

If you still can't boot OpenBSD, please find a way to get
acpidump (from other OS for instance), get screen capture
of OpenBSD kernel stopped booting than submit these to bugs@.

Various ACPI problems on various IBM hardware

[Frederic URBAN]

Hello,

We have some ACPI problems with various IBM server X. Since it's a very 
early panic when kernel boot there is now access to ddb to print the 
trace. You are prompted to press any key to reboot :) It has been 
verified on IBM Server x3650 M1, M2 and M3. We are using OpenBSD 5.7, 
this panic happends with bsd.rd and bsd.mp

The system is usable when I disable acpi when booting on RAMDISK_CD and 
after the installation on GENERIC.MP

I can provide a screenshot of the KVM over LAN if you guys wants. Like 
we did in the past (Adding support of Intel 82576 on em(4)), I also can 
provide you a remote access to both oldest machines (a Server x3650 M1 
and a Server x3650 M2) with serial cable to help you to fix this. We are 
big users of OpenBSD on various systems (Dell, HP) for the first time i 
need to install a firewall on IBM hardware so if we can help, i'm ready 
to setup a lab for you.

Frédéric.
-- 
Frédéric URBAN
*Frédéric URBAN*
Ingénieur Réseaux

frederic.ur...@ircad.fr mailto:frederic.ur...@ircad.fr
Tél. : +33 (0)3 88 119 038
IRCAD France
http://www.ircad.fr/ http://www.ircad.fr/

Suivez l'IRCAD sur Facebook 
http://www.facebook.com/pages/IRCAD/193785273990141

*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE

Re: hp laptop: acpi - power adapter problem

[Mike Larkin]

On Mon, Jun 15, 2015 at 11:17:04PM +0200, Riccardo Mottola wrote:
 Hi,
 
 on my HP laptop (dmesg below) I notice that both with acpi and with apm,
 it is always reported that the power adapter is connected, even if it is
 not. The power level of the battery seems reasonable.


Can you send an acpidump please?

-ml

 
 With power cord attached:
 hw.sensors.acpitz0.temp0=56.00 degC (zone temperature)
 hw.sensors.acpiac0.indicator0=On (power supply)
 hw.sensors.acpibat0.volt0=14.80 VDC (voltage)
 hw.sensors.acpibat0.volt1=12.48 VDC (current voltage)
 hw.sensors.acpibat0.current0=unknown (rate), UNKNOWN
 hw.sensors.acpibat0.amphour0=4.10 Ah (last full capacity)
 hw.sensors.acpibat0.amphour1=0.21 Ah (warning capacity)
 hw.sensors.acpibat0.amphour2=0.12 Ah (low capacity)
 hw.sensors.acpibat0.amphour3=4.10 Ah (remaining capacity), OK
 hw.sensors.acpibat0.amphour4=6.00 Ah (design capacity)
 hw.sensors.acpibat0.raw0=0 (battery full), OK
 hw.sensors.acpibtn2.indicator0=On (lid open)
 
 Without:
 hw.sensors.acpitz0.temp0=56.00 degC (zone temperature)
 hw.sensors.acpiac0.indicator0=On (power supply)
 hw.sensors.acpibat0.volt0=14.80 VDC (voltage)
 hw.sensors.acpibat0.volt1=11.84 VDC (current voltage)
 hw.sensors.acpibat0.current0=unknown (rate), UNKNOWN
 hw.sensors.acpibat0.amphour0=4.10 Ah (last full capacity)
 hw.sensors.acpibat0.amphour1=0.21 Ah (warning capacity)
 hw.sensors.acpibat0.amphour2=0.12 Ah (low capacity)
 hw.sensors.acpibat0.amphour3=4.00 Ah (remaining capacity), OK
 hw.sensors.acpibat0.amphour4=6.00 Ah (design capacity)
 hw.sensors.acpibat0.raw0=1 (battery discharging), OK
 hw.sensors.acpibtn2.indicator0=On (lid open)
 
 
 acpiac0 seems wrong to me.
 
 Riccardo
 
 OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 2129461248 (2030MB)
 avail mem = 2068914176 (1973MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xdc010 (19 entries)
 bios0: vendor Hewlett-Packard version F.58 date 06/16/2008
 bios0: Hewlett-Packard HP Pavilion dv6500 Notebook PC
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP HPET MCFG TMOR APIC BOOT SLIC SSDT SSDT SSDT SSDT
 acpi0: wakeup devices PWRB(S4) PXSX(S3) PXSX(S4) PS2K(S3) PS2M(S3)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 2394.68 MHz
 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
 cpu0: 4MB 64b/line 16-way L2 cache
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 199MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 2194.75 MHz
 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
 cpu1: 4MB 64b/line 16-way L2 cache
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 1 (PEGP)
 acpiprt2 at acpi0: bus 2 (RP01)
 acpiprt3 at acpi0: bus 4 (RP02)
 acpiprt4 at acpi0: bus 8 (RP06)
 acpiprt5 at acpi0: bus 9 (PCIB)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpitz0 at acpi0acpitz0: THR1: failed to read _CRT
 acpitz0: THR1: failed to read _CRT
 : no critical temperature defined
 acpibtn0 at acpi0: PWRB
 acpibtn1 at acpi0: SLPB
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT0 model Primary serial   type LION oem
 Hewlett-Packard
 acpibtn2 at acpi0: LID_
 acpivideo0 at acpi0: VGA_
 acpivout0 at acpivideo0: LCD_
 acpivideo1 at acpi0: GFX0
 cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2201, 2200, 1600, 1200, 800 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c
 ppb0 at pci0 dev 1 function 0 Intel GM965 PCIE rev 0x0c: msi
 pci1 at ppb0 bus 1
 vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8400M GS rev 0xa1
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x03: apic 2 int 16
 uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x03: apic 2 int 21
 ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x03: apic 2 int 18
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
 azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x03: msi
 azalia0: codecs

hp laptop: acpi - power adapter problem

[Riccardo Mottola]

Hi,

on my HP laptop (dmesg below) I notice that both with acpi and with apm,
it is always reported that the power adapter is connected, even if it is
not. The power level of the battery seems reasonable.

With power cord attached:
hw.sensors.acpitz0.temp0=56.00 degC (zone temperature)
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpibat0.volt0=14.80 VDC (voltage)
hw.sensors.acpibat0.volt1=12.48 VDC (current voltage)
hw.sensors.acpibat0.current0=unknown (rate), UNKNOWN
hw.sensors.acpibat0.amphour0=4.10 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.21 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.12 Ah (low capacity)
hw.sensors.acpibat0.amphour3=4.10 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=6.00 Ah (design capacity)
hw.sensors.acpibat0.raw0=0 (battery full), OK
hw.sensors.acpibtn2.indicator0=On (lid open)

Without:
hw.sensors.acpitz0.temp0=56.00 degC (zone temperature)
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpibat0.volt0=14.80 VDC (voltage)
hw.sensors.acpibat0.volt1=11.84 VDC (current voltage)
hw.sensors.acpibat0.current0=unknown (rate), UNKNOWN
hw.sensors.acpibat0.amphour0=4.10 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.21 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.12 Ah (low capacity)
hw.sensors.acpibat0.amphour3=4.00 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=6.00 Ah (design capacity)
hw.sensors.acpibat0.raw0=1 (battery discharging), OK
hw.sensors.acpibtn2.indicator0=On (lid open)


acpiac0 seems wrong to me.

Riccardo

OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2129461248 (2030MB)
avail mem = 2068914176 (1973MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xdc010 (19 entries)
bios0: vendor Hewlett-Packard version F.58 date 06/16/2008
bios0: Hewlett-Packard HP Pavilion dv6500 Notebook PC
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET MCFG TMOR APIC BOOT SLIC SSDT SSDT SSDT SSDT
acpi0: wakeup devices PWRB(S4) PXSX(S3) PXSX(S4) PS2K(S3) PS2M(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 2394.68 MHz
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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 2194.75 MHz
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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEGP)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus 4 (RP02)
acpiprt4 at acpi0: bus 8 (RP06)
acpiprt5 at acpi0: bus 9 (PCIB)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpitz0 at acpi0acpitz0: THR1: failed to read _CRT
acpitz0: THR1: failed to read _CRT
: no critical temperature defined
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model Primary serial   type LION oem
Hewlett-Packard
acpibtn2 at acpi0: LID_
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCD_
acpivideo1 at acpi0: GFX0
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2201, 2200, 1600, 1200, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c
ppb0 at pci0 dev 1 function 0 Intel GM965 PCIE rev 0x0c: msi
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8400M GS rev 0xa1
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x03: apic 2 int 16
uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x03: apic 2 int 21
ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x03: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x03: msi
azalia0: codecs: Realtek ALC268, Motorola/0x3055, using Realtek ALC268
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x03: msi
pci2 at ppb1 bus 2
wpi0 at pci2 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02

Re: ACPI implementation for Aspeed AST2050

[Mike Larkin]

On Sun, Mar 29, 2015 at 11:55:49AM +0400, Denis Lapshin wrote:
 Since 4.9 till current 8510p/w read acpi temp with error (enormous
 high temp about 2000-5000 C) because SMBus data is not ready for
 reading. It seems data reading should be delayed.
 

I thought we(I) fixed this last year. If you still have a problem with
high temperature readings, this is the first I've heard of it since then.
Probably a half dozen people sent me yes this fixed it emails.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/acpi/acpitz.c?rev=1.47content-type=text/x-cvsweb-markup

As a matter of fact I fixed it *on an 8510p*.

If for some reason you are still having problems, I'd suggest sending
in a proper bug report instead of just ranting.

-ml

 Theo, you told that you don't want to implement shit in CVS
 repository. Most of ACPI code should be rewritten in new way.
 
 I have enormous high temperature reading in various ACPI zones on HP
 Compaq laptops from time to time.
 Still applying delay patch into acpiec.c to have it working.
 
 On 28.03.2015 22:48, Theo de Raadt wrote:
 Every release I need to apply a patch after upgrade for reading ACPII
 data from 8510p in time, to prevent wrong data on SMBUS. Theo replied
 that the patch will not be implemented in CVS because all ACPI must be
 rewritten in new manner. But they will do nothing since my last report...
 I doubt I said anything close to your interpretation.
 
 
 -- 
 Denis Lapshin
 mailto: den...@mindall.org

Re: ACPI implementation for Aspeed AST2050

[Stuart Henderson]

On 2015-03-29, Denis Lapshin den...@mindall.org wrote:
 The machine is DCS6005. This is an old Dell branded AMD based server 
 node. They named it as Cloud Server Node or something like that. It 
 has AST2050 installed. I would like to buy some for a project, but not 
 sure that OpenBSD support ACPI tables of this machine properly.

No idea about 6005, but there are Dell 5220/6100/6220 (and some lenovo
and supermicro) with aspeed chips that work.

Beyond that: either ask the vendor to test, or buy one and if it doesn't
work you could either try and collect enough information to allow people
to fix it, or sell it on again. Such is life when buying hardware,
especially old hardware, and not just for OpenBSD.

 Because of negative result of using hp-compaq laptop with ACPI thermal 
 zones problem I would like to know about ASPEED for sure.

I think you were unlucky there (it was fairly widely known that HP
laptops didn't work all that well with OpenBSD..). But then, if you're
willing to run with a local patch for a long period of time, that
doesn't really help to get things fixed in cvs.

Re: ACPI implementation for Aspeed AST2050

[Theo de Raadt]

Since 4.9 till current 8510p/w read acpi temp with error (enormous high 
temp about 2000-5000 C) because SMBus data is not ready for reading. It 
seems data reading should be delayed.

Theo, you told that you don't want to implement shit in CVS 
repository. Most of ACPI code should be rewritten in new way.

I have enormous high temperature reading in various ACPI zones on HP 
Compaq laptops from time to time.
Still applying delay patch into acpiec.c to have it working.

I said no such thing.  You are quite obviously interpreting somethign
I said and trying to imply malice on my part.  The malice of false
intepretation is yours alone.

Re: ACPI implementation for Aspeed AST2050

[Denis Lapshin]

Since 4.9 till current 8510p/w read acpi temp with error (enormous high 
temp about 2000-5000 C) because SMBus data is not ready for reading. It 
seems data reading should be delayed.


Theo, you told that you don't want to implement shit in CVS 
repository. Most of ACPI code should be rewritten in new way.


I have enormous high temperature reading in various ACPI zones on HP 
Compaq laptops from time to time.

Still applying delay patch into acpiec.c to have it working.

On 28.03.2015 22:48, Theo de Raadt wrote:

Every release I need to apply a patch after upgrade for reading ACPII
data from 8510p in time, to prevent wrong data on SMBUS. Theo replied
that the patch will not be implemented in CVS because all ACPI must be
rewritten in new manner. But they will do nothing since my last report...

I doubt I said anything close to your interpretation.



--
Denis Lapshin
mailto: den...@mindall.org

Re: ACPI implementation for Aspeed AST2050

[Stuart Henderson]

On 2015/03/29 11:55, Denis Lapshin wrote:
 Since 4.9 till current 8510p/w read acpi temp with error (enormous high temp
 about 2000-5000 C) because SMBus data is not ready for reading. It seems
 data reading should be delayed.
 
 Theo, you told that you don't want to implement shit in CVS repository.
 Most of ACPI code should be rewritten in new way.
 
 I have enormous high temperature reading in various ACPI zones on HP Compaq
 laptops from time to time.
 Still applying delay patch into acpiec.c to have it working.
 
 On 28.03.2015 22:48, Theo de Raadt wrote:
 Every release I need to apply a patch after upgrade for reading ACPII
 data from 8510p in time, to prevent wrong data on SMBUS. Theo replied
 that the patch will not be implemented in CVS because all ACPI must be
 rewritten in new manner. But they will do nothing since my last report...
 I doubt I said anything close to your interpretation.
 
 
 -- 
 Denis Lapshin
 mailto: den...@mindall.org
 

From what I understand of that thread, the embedded controller on those
HPs lies about when it's ready.

The diff had some definitely wrong things in it (like the local volatile
stuff) and at least 3 developers were in agreement that it was the wrong
approach. But since everybody who was affected seemed more interested in
locally patching with a quick fix rather than working on a correct diff,
what can be done?

Back to the AST2050. You need more information than that. Whether the
machine is going to work depends on more than just which ICs it has.
If your question is does anybody know if machine X works with OpenBSD
then just ask that question instead (though there is still some element
of surprise as they may have different BIOS, firmware version, etc).

I have machines with other similar Aspeed chips that work fine, but
without more details about the machines that's not useful information.

Re: ACPI implementation for Aspeed AST2050

[Denis Lapshin]

The machine is DCS6005. This is an old Dell branded AMD based server 
node. They named it as Cloud Server Node or something like that. It 
has AST2050 installed. I would like to buy some for a project, but not 
sure that OpenBSD support ACPI tables of this machine properly.


Because of negative result of using hp-compaq laptop with ACPI thermal 
zones problem I would like to know about ASPEED for sure.


As for 8510, it can have an internal SMC bug, I don't know exactly about 
this, but regretting about the problem during update from release to 
release.


That is all I have to ask.

Denis

On 29.03.2015 14:15, Stuart Henderson wrote:

On 2015/03/29 11:55, Denis Lapshin wrote:

Since 4.9 till current 8510p/w read acpi temp with error (enormous high temp
about 2000-5000 C) because SMBus data is not ready for reading. It seems
data reading should be delayed.

Theo, you told that you don't want to implement shit in CVS repository.
Most of ACPI code should be rewritten in new way.

I have enormous high temperature reading in various ACPI zones on HP Compaq
laptops from time to time.
Still applying delay patch into acpiec.c to have it working.

On 28.03.2015 22:48, Theo de Raadt wrote:

Every release I need to apply a patch after upgrade for reading ACPII
data from 8510p in time, to prevent wrong data on SMBUS. Theo replied
that the patch will not be implemented in CVS because all ACPI must be
rewritten in new manner. But they will do nothing since my last report...

I doubt I said anything close to your interpretation.


--
Denis Lapshin
mailto: den...@mindall.org


 From what I understand of that thread, the embedded controller on those
HPs lies about when it's ready.

The diff had some definitely wrong things in it (like the local volatile
stuff) and at least 3 developers were in agreement that it was the wrong
approach. But since everybody who was affected seemed more interested in
locally patching with a quick fix rather than working on a correct diff,
what can be done?

Back to the AST2050. You need more information than that. Whether the
machine is going to work depends on more than just which ICs it has.
If your question is does anybody know if machine X works with OpenBSD
then just ask that question instead (though there is still some element
of surprise as they may have different BIOS, firmware version, etc).

I have machines with other similar Aspeed chips that work fine, but
without more details about the machines that's not useful information.

Re: ACPI implementation for Aspeed AST2050

[Denis Lapshin]

I'm sorry, but the question have sense.

Using HP 8510p for four years with OpenBSD, I have a great trouble with 
reading SMBUS (data ready on it) for years.


Every release I need to apply a patch after upgrade for reading ACPII 
data from 8510p in time, to prevent wrong data on SMBUS. Theo replied 
that the patch will not be implemented in CVS because all ACPI must be 
rewritten in new manner. But they will do nothing since my last report...


All the troubles the same as four years ago. Only the patch can be 
implemented to read ACPI data on HP 8510p properly during boot, no CVS 
implemented.


So I'm interesting about AST2050 fully supported just now in CVS.

Thanks.

Denis

On 28.03.2015 16:14, Stuart Henderson wrote:

On 2015-03-28, Denis Lapshin den...@mindall.org wrote:

Hi,

Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release?

The question doesn't really make sense, ACPI is a method where the
manufacturer can supply a set of BIOS tables with instructions about
how to route interrupts, control power use etc. It isn't specifically
implemented for each vendor, it is a common standard.


This IC is present in some Dell branded Tyan products like DCS6005 cloud
nodes and some other Tyan MBs. Seems Aspeed its their own product
because these ICs can be found on all Tyan server mainboards as I can see.

Not just Tyan, a number of vendors use Aspeed controllers. Where they're
seen in servers, they usually have BMC, superio (GPIO, UARTs, PWM for fan
control etc) and basic graphics support.



--
Denis Lapshin
mailto: den...@mindall.org

Re: ACPI implementation for Aspeed AST2050

[Theo de Raadt]

Every release I need to apply a patch after upgrade for reading ACPII 
data from 8510p in time, to prevent wrong data on SMBUS. Theo replied 
that the patch will not be implemented in CVS because all ACPI must be 
rewritten in new manner. But they will do nothing since my last report...

I doubt I said anything close to your interpretation.

Re: ACPI implementation for Aspeed AST2050

[Stuart Henderson]

On 2015-03-28, Denis Lapshin den...@mindall.org wrote:
 Hi,

 Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release?

The question doesn't really make sense, ACPI is a method where the
manufacturer can supply a set of BIOS tables with instructions about
how to route interrupts, control power use etc. It isn't specifically
implemented for each vendor, it is a common standard.

 This IC is present in some Dell branded Tyan products like DCS6005 cloud 
 nodes and some other Tyan MBs. Seems Aspeed its their own product 
 because these ICs can be found on all Tyan server mainboards as I can see.

Not just Tyan, a number of vendors use Aspeed controllers. Where they're
seen in servers, they usually have BMC, superio (GPIO, UARTs, PWM for fan
control etc) and basic graphics support.

ACPI implementation for Aspeed AST2050

[Denis Lapshin]

Hi,

Has OpenBSD implemented ACPI for Aspeed AST2050 in current or release?

This IC is present in some Dell branded Tyan products like DCS6005 cloud 
nodes and some other Tyan MBs. Seems Aspeed its their own product 
because these ICs can be found on all Tyan server mainboards as I can see.


Thank you for answer in advance.

Denis

interpreting ACPI bat values

[Riccardo Mottola]

Hi all,

I want to give batmon.app ACPI support on OpenBSD.

This is what I get on my Thinkpad T60:

$ sysctl | grep acpibat
hw.sensors.acpibat0.volt0=10.80 VDC (voltage)
hw.sensors.acpibat0.volt1=12.41 VDC (current voltage)
hw.sensors.acpibat0.power0=0.00 W (rate)
hw.sensors.acpibat0.watthour0=47.16 Wh (last full capacity)
hw.sensors.acpibat0.watthour1=2.36 Wh (warning capacity)
hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity)
hw.sensors.acpibat0.watthour3=47.16 Wh (remaining capacity), OK
hw.sensors.acpibat0.watthour4=47.52 Wh (design capacity)
hw.sensors.acpibat0.raw0=0 (battery full), OK

Some questions.
If I had another battery, would I get exactly the same stuff a second 
time but e.g. with acpibat1 ? I suppose yes.


I need to interpret always e.g. the remaining capacity in such a way 
that it works across different laptop models. Is it reliable to always 
read watthour3 ? Or can I trust the description remaining capacity? 
or neither?


To know if the laptop is attached to a power source and to know if it is 
charging or discharging, what can I use?

I acpiac0 tells me if I am attached o a power outlet or not, I suppose:

hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpiac0.indicator0=Off (power supply)

however this doesn't tell me yet if it is charging. Should I check this?
hw.sensors.acpibat0.raw0=1 (battery discharging), OK
hw.sensors.acpibat0.raw0=0 (battery idle), OK
hw.sensors.acpibat0.raw0=0 (battery full), OK

being raw0 it seems that I need to check the description of the item 
instead of the actual value which is only 0 or 1, which is less desirable


Riccardo

Re: shutdown/reboot on acpi/qemu signals

[Kapetanakis Giannis]

On 13/10/14 22:50, Mike Larkin wrote:

On Mon, Oct 13, 2014 at 07:42:34PM +0100, Nux! wrote:

Hello,

I'm having an issue with my OpenBSD cloud instance in that it completely ignores the 
signals sent to it by qemu-kvm, so instead of getting shut down or rebooted gracefully it 
has to be reset.
Anyone hit this issue before and can advise on the matter?

Thanks,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


What version of OpenBSD? We fixed this in April.



I can also verify that in at least one of my vms (current / i386 / SP)
acpi shutdown now works (on ovirt/RHEV).

This was not the case a couple of months ago and I was also using 
disabled mpbios.


Thanks for the change :)

G

shutdown/reboot on acpi/qemu signals

[Nux!]

Hello,

I'm having an issue with my OpenBSD cloud instance in that it completely 
ignores the signals sent to it by qemu-kvm, so instead of getting shut down or 
rebooted gracefully it has to be reset.
Anyone hit this issue before and can advise on the matter?

Thanks,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: shutdown/reboot on acpi/qemu signals

[Giancarlo Razzolini]

On 13-10-2014 15:42, Nux! wrote:
 I'm having an issue with my OpenBSD cloud instance in that it completely
ignores the signals sent to it by qemu-kvm, so instead of getting shut down or
rebooted gracefully it has to be reset.
 Anyone hit this issue before and can advise on the matter?
Yes, this is a know issue. You need to disable mpbios on your kernel:

config -ef /bsd

ulc disable mpbios

ukc quit

This will permanently disable mpbios on your kernel. If you follow
current and recompile you kernel often, then you'll need to run this
command every time you install a new kernel. Reboot your system and
check if mpbios is disabled:

dmesg | grep mpbios

You should get this:

mpbios at bios0 not configured

Now you can try issue virsh shutdown domain of shutting it down from
virt-manager. It will also correctly shutdown the OpenBSD guest in the
event of a host shutdown.

Cheers,
Giancarlo Razzolini

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: shutdown/reboot on acpi/qemu signals

[Mike Larkin]

On Mon, Oct 13, 2014 at 07:42:34PM +0100, Nux! wrote:
 Hello,
 
 I'm having an issue with my OpenBSD cloud instance in that it completely 
 ignores the signals sent to it by qemu-kvm, so instead of getting shut down 
 or rebooted gracefully it has to be reset.
 Anyone hit this issue before and can advise on the matter?
 
 Thanks,
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 

What version of OpenBSD? We fixed this in April.

Re: shutdown/reboot on acpi/qemu signals

[Mike Larkin]

On Mon, Oct 13, 2014 at 03:51:45PM -0300, Giancarlo Razzolini wrote:
 On 13-10-2014 15:42, Nux! wrote:
  I'm having an issue with my OpenBSD cloud instance in that it completely
 ignores the signals sent to it by qemu-kvm, so instead of getting shut down or
 rebooted gracefully it has to be reset.
  Anyone hit this issue before and can advise on the matter?
 Yes, this is a know issue. You need to disable mpbios on your kernel:
 
 config -ef /bsd
 
 ulc disable mpbios
 
 ukc quit
 
 This will permanently disable mpbios on your kernel. If you follow
 current and recompile you kernel often, then you'll need to run this
 command every time you install a new kernel. Reboot your system and
 check if mpbios is disabled:
 
 dmesg | grep mpbios
 
 You should get this:
 
 mpbios at bios0 not configured
 
 Now you can try issue virsh shutdown domain of shutting it down from
 virt-manager. It will also correctly shutdown the OpenBSD guest in the
 event of a host shutdown.
 
 Cheers,
 Giancarlo Razzolini
 
 [demime 1.01d removed an attachment of type application/pkcs7-signature which 
 had a name of smime.p7s]
 

You are smoking some serious crack there.

Re: shutdown/reboot on acpi/qemu signals

[Giancarlo Razzolini]

On 13-10-2014 16:50, Mike Larkin wrote:
 You are smoking some serious crack there.
This is the only thing that works for me on all my OpenBSD virtualized
installations. And I'm running 5.5 stable on all of them. I can't really
speak for 5.6, since I don't run current on my production systems. So
no, I'm not smoking crack.

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: shutdown/reboot on acpi/qemu signals

[Mike Larkin]

On Mon, Oct 13, 2014 at 07:02:36PM -0300, Giancarlo Razzolini wrote:
 On 13-10-2014 16:50, Mike Larkin wrote:
  You are smoking some serious crack there.
 This is the only thing that works for me on all my OpenBSD virtualized
 installations. And I'm running 5.5 stable on all of them. I can't really
 speak for 5.6, since I don't run current on my production systems. So
 no, I'm not smoking crack.
 
 Cheers
 
 [demime 1.01d removed an attachment of type application/pkcs7-signature which 
 had a name of smime.p7s]
 

Disabling random parts of the kernel without understanding what you are doing
is certainly smoking crack. I doubt you heard disable mpbios as a valid 
solution from any OpenBSD developer.

The fix for this issue went in after 5.5. So if you don't want to update to
-current, I'd ask that you don't advise other people to follow you down
untested/unsupported paths.

Re: shutdown/reboot on acpi/qemu signals

[Giancarlo Razzolini]

On 13-10-2014 19:12, Mike Larkin wrote:
 isabling random parts of the kernel without understanding what you are
doing
 is certainly smoking crack. I doubt you heard disable mpbios as a valid
 solution from any OpenBSD developer.
No I didn't. I found it on a very old article, refering to OpenBSD 4.8
if I'm not mistaken. I followed the issue to some extent, IIRC it had
something to do with the seabios that is used with qemu. And, since I
needed my machines to proper shutdown, I tried that and it worked.

 The fix for this issue went in after 5.5. So if you don't want to update to
 -current, I'd ask that you don't advise other people to follow you down
 untested/unsupported paths.
When you mentioned April, I figured it didn't went in on 5.5. Just as a
note, I've been doing this since 5.4, and on several machines, with the
most varied host/guest configuration, so I can't really say that I
didn't tested. It might be unsupported, but it does the job. If the OP
follows my advice and it works, better for him. If not, then he can just
enable mpbios again on his kernel and try something else.

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: shutdown/reboot on acpi/qemu signals

[Nux!]

Giancarlo,

Thanks, but for me it did not work, the guest fails to boot after this change.
I'll wait for 5.6 for more serious work on KVM.

Thanks!

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Giancarlo Razzolini grazzol...@gmail.com
 To: Nux! n...@li.nux.ro, misc@openbsd.org
 Sent: Monday, 13 October, 2014 19:51:45
 Subject: Re: shutdown/reboot on acpi/qemu signals

 On 13-10-2014 15:42, Nux! wrote:
 I'm having an issue with my OpenBSD cloud instance in that it completely 
 ignores
 the signals sent to it by qemu-kvm, so instead of getting shut down or 
 rebooted
 gracefully it has to be reset.
 Anyone hit this issue before and can advise on the matter?
 Yes, this is a know issue. You need to disable mpbios on your kernel:
 
 config -ef /bsd
 
 ulc disable mpbios
 
 ukc quit
 
 This will permanently disable mpbios on your kernel. If you follow
 current and recompile you kernel often, then you'll need to run this
 command every time you install a new kernel. Reboot your system and
 check if mpbios is disabled:
 
 dmesg | grep mpbios
 
 You should get this:
 
 mpbios at bios0 not configured
 
 Now you can try issue virsh shutdown domain of shutting it down from
 virt-manager. It will also correctly shutdown the OpenBSD guest in the
 event of a host shutdown.
 
 Cheers,
 Giancarlo Razzolini

Re: shutdown/reboot on acpi/qemu signals

[Giancarlo Razzolini]

On 13-10-2014 19:56, Nux! wrote:
 Thanks, but for me it did not work, the guest fails to boot after this
change.
 I'll wait for 5.6 for more serious work on KVM.
Which kernel you're using? The bsd or the bsd.mp? Which message appear
on the boot? Which linux/qemu-kvm version?

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: shutdown/reboot on acpi/qemu signals

[Theo de Raadt]

 On 13-10-2014 19:56, Nux! wrote:
  Thanks, but for me it did not work, the guest fails to boot after this
 change.
  I'll wait for 5.6 for more serious work on KVM.
 Which kernel you're using? The bsd or the bsd.mp? Which message appear
 on the boot? Which linux/qemu-kvm version?

Why -- do you think anyone would follow your advice?

acpi error running openbsd snapshot 20140820 (amd64)

[Wesley MOUEDINE ASSABY]

Hi,

Running the install56.fs from an usb key give me the following error :
http://pbrd.co/1rWT1Us

So i disabled acpi using UKC to be able to install :
http://pbrd.co/1rWUqL0

OpenBSD is installed now, but running it with acpi support give me a 
kernel panic :

http://pbrd.co/1rWTCFX

trace :
http://pbrd.co/1rWTKVS
http://pbrd.co/1rWTUws

and ps :
http://pbrd.co/1rWU1bl

Below, dmesg without acpi support :
OpenBSD 5.6-current (GENERIC.MP) #336: Tue Aug 19 20:39:19 MDT 2014

dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 1996161024 (1903MB)
avail mem = 1934336000 (1844MB)
User Kernel Config
UKC disable acpi
358 acpi0 disabled
UKC quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfced0 (28 entries)
bios0: vendor American Megatrends Inc. version P1.60 date 06/12/2007
acpi at bios0 not configured
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, 2411.13 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully 
associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully 
associative

mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, 2410.78 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully 
associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully 
associative

mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type PCI
mpbios0: bus 2 is type PCI
mpbios0: bus 3 is type PCI
mpbios0: bus 4 is type PCI
mpbios0: bus 5 is type ISA
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
cpu0: PowerNow! K8 2411 MHz: speeds: 2500 2400 2200 2000 1800 1000 MHz
pci0 at mainbus0 bus 0
NVIDIA MCP61 Memory rev 0xa1 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 NVIDIA MCP61 ISA rev 0xa2
nviic0 at pci0 dev 1 function 1 NVIDIA MCP61 SMBus rev 0xa2
iic0 at nviic0
iic0: addr 0x4c 00=28 01=2f 02=80 03=01 04=06 05=46 06=00 07=46 08=00 
10=60 11=00 12=00 13=00 14=00 19=6e 20=55 21=0a bf=06 e0=bb e1=c0 e2=82 
e3=bb e4=c0 e5=2f e6=29 e7=68 e8=82 eb=4f ec=02 f1=20 f2=00 f3=10 f4=80 
f5=00 f7=00 f8=00 f9=02 fa=00 fb=4c fc=4f fd=37 fe=5c ff=01 words 
00=29ff 01=2fff 02=80ff 03=01ff 04=06ff 05=46ff 06=00ff 07=46ff

spdmem0 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-6400CL5
iic1 at nviic0
NVIDIA MCP61 Memory rev 0xa2 at pci0 dev 1 function 2 not configured
ohci0 at pci0 dev 2 function 0 NVIDIA MCP61 USB rev 0xa2: apic 2 int 
5, version 1.0, legacy support
ehci0 at pci0 dev 2 function 1 NVIDIA MCP61 USB rev 0xa2: apic 2 int 
10

usb0 at ehci0: USB revision 2.0
uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1
ppb0 at pci0 dev 4 function 0 NVIDIA MCP61 rev 0xa1
pci1 at ppb0 bus 1
rl0 at pci1 dev 8 function 0 Realtek 8139 rev 0x10: apic 2 int 11, 
address 00:50:fc:47:20:a0

rlphy0 at rl0 phy 0: RTL internal PHY
rl1 at pci1 dev 10 function 0 Realtek 8139 rev 0x10: apic 2 int 5, 
address 00:50:bf:93:3f:78

rlphy1 at rl1 phy 0: RTL internal PHY
azalia0 at pci0 dev 5 function 0 NVIDIA MCP61 HD Audio rev 0xa2: apic 
2 int 11

azalia0: codecs: Realtek ALC888
audio0 at azalia0
pciide0 at pci0 dev 6 function 0 NVIDIA MCP61 IDE rev 0xa2: DMA, 
channel 0 configured to compatibility, channel 1 configured to 
compatibility

pciide0: channel 0 disabled (no drives)
pciide0: channel 1 ignored (disabled)
nfe0 at pci0 dev 7 function 0 NVIDIA MCP61 LAN rev 0xa2: apic 2 int 
10, address 00:19:66:3a:de:a4

rlphy2 at nfe0 phy 1: RTL8201L 10/100 PHY, rev. 1
pciide1 at pci0 dev 8 function 0 NVIDIA MCP61 SATA rev 0xa2: DMA
pciide1: using apic 2 int 10 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: ST3808110AS
wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
atapiscsi0 at pciide1 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: HL-DT-ST, DVD-ROM GDRH20N, 0L02 ATAPI 
5/cdrom removable

cd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
pciide2 at pci0 dev 8 function 1 NVIDIA MCP61 SATA rev 0xa2: DMA
pciide2: using apic 2 int 10 for native-PCI interrupt
ppb1 at pci0 dev 9 function 0 NVIDIA MCP61 PCIE rev 0xa2
pci2 at ppb1 bus 2
ppb2 at pci0 dev 11 function 0

Re: acpi error running openbsd snapshot 20140820 (amd64)

[Mike Larkin]

On Wed, Aug 20, 2014 at 12:34:24PM +0400, Wesley MOUEDINE ASSABY wrote:
 Hi,
 
 Running the install56.fs from an usb key give me the following error :
 http://pbrd.co/1rWT1Us
 
 So i disabled acpi using UKC to be able to install :
 http://pbrd.co/1rWUqL0
 
 OpenBSD is installed now, but running it with acpi support give me a
 kernel panic :
 http://pbrd.co/1rWTCFX
 
 trace :
 http://pbrd.co/1rWTKVS
 http://pbrd.co/1rWTUws
 
 and ps :
 http://pbrd.co/1rWU1bl

So you expect us to help you when:

1. You've been randomly disabling code in the kernel.

2. You're claiming the bug is somehow related to acpi
and yet you've provided us with no acpidump.

What would your mechanic say if you took your car to the garage and said
My engine is making a strange sound, but I'm not going to tell you what
sound it's making. By the way, I've unplugged some random wires somewhere
in the engine compartment.

-ml

 
 Below, dmesg without acpi support :
 OpenBSD 5.6-current (GENERIC.MP) #336: Tue Aug 19 20:39:19 MDT 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 1996161024 (1903MB)
 avail mem = 1934336000 (1844MB)
 User Kernel Config
 UKC disable acpi
 358 acpi0 disabled
 UKC quit
 Continuing...
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfced0 (28 entries)
 bios0: vendor American Megatrends Inc. version P1.60 date 06/12/2007
 acpi at bios0 not configured
 mpbios0 at bios0: Intel MP Specification 1.4
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, 2411.13 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
 512KB 64b/line 16-way L2 cache
 cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully
 associative
 cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully
 associative
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 200MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, 2410.78 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
 cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
 512KB 64b/line 16-way L2 cache
 cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully
 associative
 cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully
 associative
 mpbios0: bus 0 is type PCI
 mpbios0: bus 1 is type PCI
 mpbios0: bus 2 is type PCI
 mpbios0: bus 3 is type PCI
 mpbios0: bus 4 is type PCI
 mpbios0: bus 5 is type ISA
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
 cpu0: PowerNow! K8 2411 MHz: speeds: 2500 2400 2200 2000 1800 1000 MHz
 pci0 at mainbus0 bus 0
 NVIDIA MCP61 Memory rev 0xa1 at pci0 dev 0 function 0 not configured
 pcib0 at pci0 dev 1 function 0 NVIDIA MCP61 ISA rev 0xa2
 nviic0 at pci0 dev 1 function 1 NVIDIA MCP61 SMBus rev 0xa2
 iic0 at nviic0
 iic0: addr 0x4c 00=28 01=2f 02=80 03=01 04=06 05=46 06=00 07=46
 08=00 10=60 11=00 12=00 13=00 14=00 19=6e 20=55 21=0a bf=06 e0=bb
 e1=c0 e2=82 e3=bb e4=c0 e5=2f e6=29 e7=68 e8=82 eb=4f ec=02 f1=20
 f2=00 f3=10 f4=80 f5=00 f7=00 f8=00 f9=02 fa=00 fb=4c fc=4f fd=37
 fe=5c ff=01 words 00=29ff 01=2fff 02=80ff 03=01ff 04=06ff 05=46ff
 06=00ff 07=46ff
 spdmem0 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-6400CL5
 iic1 at nviic0
 NVIDIA MCP61 Memory rev 0xa2 at pci0 dev 1 function 2 not configured
 ohci0 at pci0 dev 2 function 0 NVIDIA MCP61 USB rev 0xa2: apic 2
 int 5, version 1.0, legacy support
 ehci0 at pci0 dev 2 function 1 NVIDIA MCP61 USB rev 0xa2: apic 2
 int 10
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1
 ppb0 at pci0 dev 4 function 0 NVIDIA MCP61 rev 0xa1
 pci1 at ppb0 bus 1
 rl0 at pci1 dev 8 function 0 Realtek 8139 rev 0x10: apic 2 int 11,
 address 00:50:fc:47:20:a0
 rlphy0 at rl0 phy 0: RTL internal PHY
 rl1 at pci1 dev 10 function 0 Realtek 8139 rev 0x10: apic 2 int 5,
 address 00:50:bf:93:3f:78
 rlphy1 at rl1 phy 0: RTL internal PHY
 azalia0 at pci0 dev 5 function 0 NVIDIA MCP61 HD Audio rev 0xa2:
 apic 2 int 11
 azalia0: codecs: Realtek ALC888
 audio0 at azalia0
 pciide0 at pci0 dev 6 function 0 NVIDIA MCP61 IDE rev 0xa2: DMA,
 channel 0 configured to compatibility, channel 1 configured to
 compatibility
 pciide0: channel 0 disabled (no drives)
 pciide0: channel 1 ignored (disabled)
 nfe0 at pci0 dev 7 function 0 NVIDIA MCP61 LAN rev 0xa2: apic 2
 int 10, address 00:19:66:3a:de:a4
 rlphy2 at nfe0 phy 1: RTL8201L 10/100 PHY, rev. 1
 pciide1 at pci0 dev 8 function 0 NVIDIA MCP61 SATA rev 0xa2: DMA
 pciide1: using apic 2 int 10 for native-PCI interrupt
 wd0

Re: acpi error running openbsd snapshot 20140820 (amd64)

[Wesley MOUEDINE ASSABY]

On 20.08.2014 19:27, Mike Larkin wrote:
On Wed, Aug 20, 2014 at 12:34:24PM +0400, Wesley MOUEDINE ASSABY 
wrote:

Hi,

Running the install56.fs from an usb key give me the following error 
:

http://pbrd.co/1rWT1Us

So i disabled acpi using UKC to be able to install :
http://pbrd.co/1rWUqL0

OpenBSD is installed now, but running it with acpi support give me a
kernel panic :
http://pbrd.co/1rWTCFX

trace :
http://pbrd.co/1rWTKVS
http://pbrd.co/1rWTUws

and ps :
http://pbrd.co/1rWU1bl


So you expect us to help you when:

1. You've been randomly disabling code in the kernel.


I can't install it with acpi support as i mentioned.
The error with acpi at install process :

Running the install56.fs from an usb key give me the following error 
:

http://pbrd.co/1rWT1Us



2. You're claiming the bug is somehow related to acpi
and yet you've provided us with no acpidump.


If you look the error message :
http://pbrd.co/1rWT1Us

How can i get the acpidump if there 's no ddb prompt ? :)

What would your mechanic say if you took your car to the garage and 
said
My engine is making a strange sound, but I'm not going to tell you 
what
sound it's making. By the way, I've unplugged some random wires 
somewhere

in the engine compartment.


Criticism is easy :)

==wma

Re: acpi error running openbsd snapshot 20140820 (amd64)

[Peter Hessler]

On 2014 Aug 20 (Wed) at 19:47:57 +0400 (+0400), Wesley MOUEDINE ASSABY wrote:
:On 20.08.2014 19:27, Mike Larkin wrote:
:On Wed, Aug 20, 2014 at 12:34:24PM +0400, Wesley MOUEDINE ASSABY wrote:
:Hi,
:
:Running the install56.fs from an usb key give me the following error :
:http://pbrd.co/1rWT1Us
:
:So i disabled acpi using UKC to be able to install :
:http://pbrd.co/1rWUqL0
:
:OpenBSD is installed now, but running it with acpi support give me a
:kernel panic :
:http://pbrd.co/1rWTCFX
:
:trace :
:http://pbrd.co/1rWTKVS
:http://pbrd.co/1rWTUws
:
:and ps :
:http://pbrd.co/1rWU1bl
:
:So you expect us to help you when:
:
:1. You've been randomly disabling code in the kernel.
:
:I can't install it with acpi support as i mentioned.
:The error with acpi at install process :
:
:Running the install56.fs from an usb key give me the following error :
:http://pbrd.co/1rWT1Us
:
:2. You're claiming the bug is somehow related to acpi
:and yet you've provided us with no acpidump.
:
:If you look the error message :
:http://pbrd.co/1rWT1Us
:
:How can i get the acpidump if there 's no ddb prompt ? :)
:

you run the command.


:What would your mechanic say if you took your car to the garage and said
:My engine is making a strange sound, but I'm not going to tell you what
:sound it's making. By the way, I've unplugged some random wires somewhere
:in the engine compartment.
:
:Criticism is easy :)
:

I applaud you for insulting the guy that could actually fix acpi bugs.
Good job.

:==wma
:

-- 
Expense Accounts, n.:
Corporate food stamps.

Re: acpi error running openbsd snapshot 20140820 (amd64)

[Mike Larkin]

On Wed, Aug 20, 2014 at 07:47:57PM +0400, Wesley MOUEDINE ASSABY wrote:
 On 20.08.2014 19:27, Mike Larkin wrote:
 On Wed, Aug 20, 2014 at 12:34:24PM +0400, Wesley MOUEDINE ASSABY
 wrote:
 Hi,
 
 Running the install56.fs from an usb key give me the following
 error :
 http://pbrd.co/1rWT1Us
 
 So i disabled acpi using UKC to be able to install :
 http://pbrd.co/1rWUqL0
 
 OpenBSD is installed now, but running it with acpi support give me a
 kernel panic :
 http://pbrd.co/1rWTCFX
 
 trace :
 http://pbrd.co/1rWTKVS
 http://pbrd.co/1rWTUws
 
 and ps :
 http://pbrd.co/1rWU1bl
 
 So you expect us to help you when:
 
 1. You've been randomly disabling code in the kernel.
 
 I can't install it with acpi support as i mentioned.
 The error with acpi at install process :
 
 Running the install56.fs from an usb key give me the following
 error :
 http://pbrd.co/1rWT1Us
 
 2. You're claiming the bug is somehow related to acpi
 and yet you've provided us with no acpidump.
 
 If you look the error message :
 http://pbrd.co/1rWT1Us
 
 How can i get the acpidump if there 's no ddb prompt ? :)
 

man acpidump

 What would your mechanic say if you took your car to the garage
 and said
 My engine is making a strange sound, but I'm not going to tell
 you what
 sound it's making. By the way, I've unplugged some random wires
 somewhere
 in the engine compartment.
 
 Criticism is easy :)

Asking for help and providing a substandard bug report is easier. 

Re: acpi error running openbsd snapshot 20140820 (amd64)

[Wesley MOUEDINE ASSABY]

How can i get the acpidump if there 's no ddb prompt ? :)



man acpidump


Reading FAQ, there's no acpidump informations...the same for acpi(4)

I will post the dump. Thank you very much.




What would your mechanic say if you took your car to the garage
and said
My engine is making a strange sound, but I'm not going to tell
you what
sound it's making. By the way, I've unplugged some random wires
somewhere
in the engine compartment.

Criticism is easy :)


Asking for help and providing a substandard bug report is easier.


+1 :)

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Jason Crawford]

I can also confirm that newest snapshot works now.

On Thu, Jun 26, 2014 at 7:45 AM, Nils R m...@hxgn.net wrote:
 Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Jason Crawford]

I know on my laptop no acpi meant doesn't work. My saving grace is I
always keep a kernel from the previous snapshot I tried as obsd. So if
bsd doesn't work, I just boot from that. Do you have an older snapshot
kernel you can tell tech support to boot into?

On Thu, Jun 26, 2014 at 7:36 PM, Scott Vanderbilt li...@datagenic.com wrote:
 Having done a little man page reading on boot-time configuration, I learned
 about the existence of ukc. I'm wondering whether something like

   ukc disable acpi0

 might circumvent the kernel panic and allow the boot to successfully
 complete. I'm hoping that since this is a server, ACPI is non-essential.
 Just grasping at straws in an effort to get this machine up and running
 again.

 Thanks.




 On 6/26/2014 4:21 PM, Scott Vanderbilt wrote:

 I have this exact same kernel panic. Unfortunately, it's occurring on a
 host at a remote co-lo. Does anyone know a way that I can get the
 on-site tech to suppress the assertion by way of some boot-time
 configuration? Then at least I can get this machine up and running so I
 can immediately upgrade to the latest snapshot, which apparently fixes
 this issue.

 Thanks.


 On 6/25/2014 8:05 AM, Jason Crawford wrote:

 My system panic's from the KASSERT() call at line 2269 after dsdt.c was
 updated to 1.210.

 All I have is the basic panic message and the dmesg from the last known
 working snapshot kernel. I tried to get more information but my USB
 keyboard does not work in the kernel debugger, and my on-board keyboard
 no longer works at all (I use the laptop as a desktop now). I typed up
 everything I could see of that panic message by hand.

 Any patches that need to be tested I will be glad to try out.

 Here's the panic message and dmesg output.

 --- panic ---
 acpi0 at bios0: rev 2panic: kernel diagnostic assertion
 rgn-v_opregion.iobase % sz == 0 failed: file
 ../../../../dev/acpi/dsdt.c, line 2269
 Stopped atDebugger+0x9:leave
 panic() at panic+0xfe
 __assert() at __assert+0x25
 aml_rwgas() at aml_rwgas+0x1fd
 aml_rwfield() at aml_rwfield+0x205
 aml_eval() at aml_eval+0x1ae
 aml_parse() at aml_parse+0x183d
 aml_parse() at aml_parse+0x1ff
 aml_parse() at aml_parse+0x1ff
 aml_parse() at aml_parse+0x1ff
 end trace frame: 0x81ef48f0, count: 0
 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
 PANIC!
 IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS,
 TOO.
 DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!


 --- dmesg ---
 OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 4209770496 (4014MB)
 avail mem = 4088930304 (3899MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries)
 bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009
 bios0: Gateway NV53
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET
 acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4)
 PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3)
 OHC3(S3) OHC4(S3) EHC0(S3) [...]
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz
 cpu0:

 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

 T,ITSC
 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
 associative
 cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
 associative
 cpu0: AMD erratum 721 detected and fixed
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 200MHz
 cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz
 cpu1:

 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

 T,ITSC
 cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
 64b/line 16-way L2 cache
 cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully
 associative
 cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully
 associative
 cpu1: AMD erratum 721 detected and fixed
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
 acpimcfg0 at acpi0 addr 0xe000, bus 0-9
 acpihpet0 at acpi0: 14318180 Hz
 acpi0: unable to load \\_SB_.PCI0

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Scott Vanderbilt]

Unfortunately, not. It was a fresh install from a CD image to a hard 
drive which I then shipped to the ISP for installation, which replaced a 
failing drive in my machine co-located there.


In any event, bypassing acpi in ukc got the machine up again, and I was 
able to upgrade to the latest snapshot which does indeed resolve the 
issue. All is well again.


Thanks to Chris for confirming the boot-time config option.

On 6/27/2014 6:44 AM, Jason Crawford wrote:

I know on my laptop no acpi meant doesn't work. My saving grace is I
always keep a kernel from the previous snapshot I tried as obsd. So if
bsd doesn't work, I just boot from that. Do you have an older snapshot
kernel you can tell tech support to boot into?

On Thu, Jun 26, 2014 at 7:36 PM, Scott Vanderbilt li...@datagenic.com wrote:

Having done a little man page reading on boot-time configuration, I learned
about the existence of ukc. I'm wondering whether something like

   ukc disable acpi0

might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.

Thanks.




On 6/26/2014 4:21 PM, Scott Vanderbilt wrote:


I have this exact same kernel panic. Unfortunately, it's occurring on a
host at a remote co-lo. Does anyone know a way that I can get the
on-site tech to suppress the assertion by way of some boot-time
configuration? Then at least I can get this machine up and running so I
can immediately upgrade to the latest snapshot, which apparently fixes
this issue.

Thanks.


On 6/25/2014 8:05 AM, Jason Crawford wrote:


My system panic's from the KASSERT() call at line 2269 after dsdt.c was
updated to 1.210.

All I have is the basic panic message and the dmesg from the last known
working snapshot kernel. I tried to get more information but my USB
keyboard does not work in the kernel debugger, and my on-board keyboard
no longer works at all (I use the laptop as a desktop now). I typed up
everything I could see of that panic message by hand.

Any patches that need to be tested I will be glad to try out.

Here's the panic message and dmesg output.

--- panic ---
acpi0 at bios0: rev 2panic: kernel diagnostic assertion
rgn-v_opregion.iobase % sz == 0 failed: file
../../../../dev/acpi/dsdt.c, line 2269
Stopped atDebugger+0x9:leave
panic() at panic+0xfe
__assert() at __assert+0x25
aml_rwgas() at aml_rwgas+0x1fd
aml_rwfield() at aml_rwfield+0x205
aml_eval() at aml_eval+0x1ae
aml_parse() at aml_parse+0x183d
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
aml_parse() at aml_parse+0x1ff
end trace frame: 0x81ef48f0, count: 0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS,
TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!


--- dmesg ---
OpenBSD 5.5-current (GENERIC.MP) #219: Thu Jun 19 22:16:22 MDT 2014
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4209770496 (4014MB)
avail mem = 4088930304 (3899MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdbeda000 (35 entries)
bios0: vendor Phoenix Technologies LTD version V1.04 date 10/22/2009
bios0: Gateway NV53
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT APIC MCFG HPET
acpi0: wakeup devices LID0(S3) SLPB(S3) PB2_(S4) PB3_(S4) PB4_(S4)
PB5_(S4) PB6_(S4) PB7_(S4) PB9_(S4) PB10(S4) OHC0(S3) OHC1(S3) OHC2(S3)
OHC3(S3) OHC4(S3) EHC0(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II Dual-Core M300, 2000.97 MHz
cpu0:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

T,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.03 MHz
cpu1:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINI

T,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Stuart Henderson]

On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
 Having done a little man page reading on boot-time configuration, I 
 learned about the existence of ukc. I'm wondering whether something like

ukc disable acpi0

 might circumvent the kernel panic and allow the boot to successfully 
 complete. I'm hoping that since this is a server, ACPI is non-essential. 
 Just grasping at straws in an effort to get this machine up and running 
 again.

I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years or so - servers, laptops, standard PCs.

In an emergency such as this you might get away with it briefly, but
some devices are likely not to work, and it's not recommended leaving
it like that for any length of time, ACPI is involved in a lot of
system controls (thermal controls, power etc) and most modern machines
are just not designed/tested to work without it.

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Theo de Raadt]

 On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
  Having done a little man page reading on boot-time configuration, I 
  learned about the existence of ukc. I'm wondering whether something like
 
 ukc disable acpi0
 
  might circumvent the kernel panic and allow the boot to successfully 
  complete. I'm hoping that since this is a server, ACPI is non-essential. 
  Just grasping at straws in an effort to get this machine up and running 
  again.
 
 I think you should consider ACPI essential on pretty much any x86
 machine from the last 4-5 years or so - servers, laptops, standard PCs.

Yes, ACPI is essential.  It is the modern way to interface to the hardware;
it is the modern BIOS API.

The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and
rotting on most machines these days.   The vendors include support, but they
do not verify their correctness.

 In an emergency such as this you might get away with it briefly, but
 some devices are likely not to work, and it's not recommended leaving
 it like that for any length of time, ACPI is involved in a lot of
 system controls (thermal controls, power etc) and most modern machines
 are just not designed/tested to work without it.

Stuart is correct.  Those of you turning off ACPI are relying on an
interface model we have repeatedly described as broken.

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Scott Vanderbilt]

On 6/27/2014 12:10 PM, Stuart Henderson wrote:

On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:

Having done a little man page reading on boot-time configuration, I
learned about the existence of ukc. I'm wondering whether something like

ukc disable acpi0

might circumvent the kernel panic and allow the boot to successfully
complete. I'm hoping that since this is a server, ACPI is non-essential.
Just grasping at straws in an effort to get this machine up and running
again.


I think you should consider ACPI essential on pretty much any x86
machine from the last 4-5 years or so - servers, laptops, standard PCs.

In an emergency such as this you might get away with it briefly, but
some devices are likely not to work, and it's not recommended leaving
it like that for any length of time, ACPI is involved in a lot of
system controls (thermal controls, power etc) and most modern machines
are just not designed/tested to work without it.



Thanks for clarifying.

Disabling acpi was only meant to be a stopgap measure so I could get 
around the assertion in the kernel that caused a panic on boot. Once I 
was able to boot the machine, I upgraded to a later snapshot in which 
the assertion was removed. I never intended to permanently disable acpi. 
As the machine was at a remote co-lo, I felt had no other choice.


Is there some better way that I should have handled this situation?

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Mike Larkin]

On Fri, Jun 27, 2014 at 01:15:59PM -0600, Theo de Raadt wrote:
  On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
   Having done a little man page reading on boot-time configuration, I 
   learned about the existence of ukc. I'm wondering whether something like
  
  ukc disable acpi0
  
   might circumvent the kernel panic and allow the boot to successfully 
   complete. I'm hoping that since this is a server, ACPI is non-essential. 
   Just grasping at straws in an effort to get this machine up and running 
   again.
  
  I think you should consider ACPI essential on pretty much any x86
  machine from the last 4-5 years or so - servers, laptops, standard PCs.
 
 Yes, ACPI is essential.  It is the modern way to interface to the hardware;
 it is the modern BIOS API.
 
 The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and
 rotting on most machines these days.   The vendors include support, but they
 do not verify their correctness.
 
  In an emergency such as this you might get away with it briefly, but
  some devices are likely not to work, and it's not recommended leaving
  it like that for any length of time, ACPI is involved in a lot of
  system controls (thermal controls, power etc) and most modern machines
  are just not designed/tested to work without it.
 
 Stuart is correct.  Those of you turning off ACPI are relying on an
 interface model we have repeatedly described as broken.
 

 I have some hardware that doesn't work. Should I just disable mainbus? That
way it doesn't attach.

Maybe that would fix the problem.

-ml

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Mike Larkin]

On Fri, Jun 27, 2014 at 12:37:33PM -0700, Scott Vanderbilt wrote:
 On 6/27/2014 12:10 PM, Stuart Henderson wrote:
 On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
 Having done a little man page reading on boot-time configuration, I
 learned about the existence of ukc. I'm wondering whether something like
 
 ukc disable acpi0
 
 might circumvent the kernel panic and allow the boot to successfully
 complete. I'm hoping that since this is a server, ACPI is non-essential.
 Just grasping at straws in an effort to get this machine up and running
 again.
 
 I think you should consider ACPI essential on pretty much any x86
 machine from the last 4-5 years or so - servers, laptops, standard PCs.
 
 In an emergency such as this you might get away with it briefly, but
 some devices are likely not to work, and it's not recommended leaving
 it like that for any length of time, ACPI is involved in a lot of
 system controls (thermal controls, power etc) and most modern machines
 are just not designed/tested to work without it.
 
 
 Thanks for clarifying.
 
 Disabling acpi was only meant to be a stopgap measure so I could get
 around the assertion in the kernel that caused a panic on boot. Once
 I was able to boot the machine, I upgraded to a later snapshot in
 which the assertion was removed. I never intended to permanently
 disable acpi. As the machine was at a remote co-lo, I felt had no
 other choice.
 
 Is there some better way that I should have handled this situation?
 

Keep another kernel in / that is known working.

-ml

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[patrick keshishian]

On 6/27/14, Theo de Raadt dera...@cvs.openbsd.org wrote:
 On 2014-06-26, Scott Vanderbilt li...@datagenic.com wrote:
  Having done a little man page reading on boot-time configuration, I
  learned about the existence of ukc. I'm wondering whether something
  like
 
 ukc disable acpi0
 
  might circumvent the kernel panic and allow the boot to successfully
  complete. I'm hoping that since this is a server, ACPI is non-essential.
 
  Just grasping at straws in an effort to get this machine up and running
 
  again.

 I think you should consider ACPI essential on pretty much any x86
 machine from the last 4-5 years or so - servers, laptops, standard PCs.

 Yes, ACPI is essential.  It is the modern way to interface to the hardware;
 it is the modern BIOS API.

viva pragmatism!
http://www.openbsd.org/lyrics.html#45
:)
--patrick


 The other BIOS interfaces (MPBIOS and PCIBIOS) are totally unreliable and
 rotting on most machines these days.   The vendors include support, but
 they
 do not verify their correctness.

 In an emergency such as this you might get away with it briefly, but
 some devices are likely not to work, and it's not recommended leaving
 it like that for any length of time, ACPI is involved in a lot of
 system controls (thermal controls, power etc) and most modern machines
 are just not designed/tested to work without it.

 Stuart is correct.  Those of you turning off ACPI are relying on an
 interface model we have repeatedly described as broken.

Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change

[Nils R]

Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!