Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
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
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
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
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
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
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
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
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
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
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
Works now with the latest snapshot (dsdt.c rev. 1.211), thanks!
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
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._INI.EXH2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB2_) acpiprt2 at acpi0: bus -1 (PB3_) acpiprt3 at acpi0: bus 3 (PB4_) acpiprt4 at acpi0: bus -1 (PB5_) acpiprt5 at acpi0: bus 9 (PB6_) acpiprt6 at acpi0: bus -1 (PB7_) acpiprt7 at acpi0: bus -1 (PB9_) acpiprt8 at acpi0: bus -1 (PB10) acpiprt9 at acpi0: bus 10 (P2P_) acpiprt10 at acpi0: bus 1 (AGP_) acpiec0 at acpi0 acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpitz0 at acpi0: critical temperature is 95 degC acpitz1 at acpi0: critical temperature is 95 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpibtn2 at acpi0: SLPB acpibat0 at acpi0: BAT0 model AS09A61 serial 4548 type LION oem 494453 acpiac0 at acpi0: AC unit online acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivout0 at acpivideo1: LCD_ cpu0: 2000 MHz: speeds: 2000 1400 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
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._INI.EXH2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB2_) acpiprt2 at acpi0: bus -1 (PB3_) acpiprt3 at acpi0: bus 3 (PB4_) acpiprt4 at acpi0: bus -1 (PB5_) acpiprt5 at acpi0: bus 9 (PB6_) acpiprt6 at acpi0: bus -1 (PB7_) acpiprt7 at acpi0: bus -1 (PB9_) acpiprt8 at acpi0: bus -1 (PB10) acpiprt9 at acpi0: bus 10 (P2P_) acpiprt10 at acpi0: bus 1 (AGP_) acpiec0 at acpi0 acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
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 That or disable acpi 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. Yeah, try it. More likely to work without an MP kernel. Maybe disable acpi; boot bsd.sp ?
kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
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._INI.EXH2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB2_) acpiprt2 at acpi0: bus -1 (PB3_) acpiprt3 at acpi0: bus 3 (PB4_) acpiprt4 at acpi0: bus -1 (PB5_) acpiprt5 at acpi0: bus 9 (PB6_) acpiprt6 at acpi0: bus -1 (PB7_) acpiprt7 at acpi0: bus -1 (PB9_) acpiprt8 at acpi0: bus -1 (PB10) acpiprt9 at acpi0: bus 10 (P2P_) acpiprt10 at acpi0: bus 1 (AGP_) acpiec0 at acpi0 acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpitz0 at acpi0: critical temperature is 95 degC acpitz1 at acpi0: critical temperature is 95 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpibtn2 at acpi0: SLPB acpibat0 at acpi0: BAT0 model AS09A61 serial 4548 type LION oem 494453 acpiac0 at acpi0: AC unit online acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivout0 at acpivideo1: LCD_ cpu0: 2000 MHz: speeds: 2000 1400 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS880 Host rev 0x00 ppb0 at pci0 dev 1 function 0 vendor Acer, unknown product 0x9602 rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 ATI Mobility Radeon HD 4200 rev 0x00 drm0 at radeondrm0 radeondrm0: apic 2 int 18 azalia0 at pci1 dev 5 function 1 ATI Radeon HD 4200 HD Audio rev 0x00: msi azalia0: no supported codecs ppb1 at pci0 dev 4 function 0 AMD RS780 PCIE rev 0x00: msi pci2 at ppb1
Re: kernel panic from sys/dev/acpi/dsdt.c rev1.210 change
Am 25.06.2014 17:05 schrieb Jason Crawford ja...@purebsd.net: 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 at Debugger+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._INI.EXH2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB2_) acpiprt2 at acpi0: bus -1 (PB3_) acpiprt3 at acpi0: bus 3 (PB4_) acpiprt4 at acpi0: bus -1 (PB5_) acpiprt5 at acpi0: bus 9 (PB6_) acpiprt6 at acpi0: bus -1 (PB7_) acpiprt7 at acpi0: bus -1 (PB9_) acpiprt8 at acpi0: bus -1 (PB10) acpiprt9 at acpi0: bus 10 (P2P_) acpiprt10 at acpi0: bus 1 (AGP_) acpiec0 at acpi0 acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpitz0 at acpi0: critical temperature is 95 degC acpitz1 at acpi0: critical temperature is 95 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpibtn2 at acpi0: SLPB acpibat0 at acpi0: BAT0 model AS09A61 serial 4548 type LION oem 494453 acpiac0 at acpi0: AC unit online acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivout0 at acpivideo1: LCD_ cpu0: 2000 MHz: speeds: 2000 1400 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS880 Host rev 0x00 ppb0 at pci0 dev 1 function 0 vendor Acer, unknown product 0x9602 rev 0x00 pci1 at ppb0 bus 1 radeondrm0
