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: reboot after kernel panic on 7.2

[Stuart Henderson]

On 2023-03-05, mabi  wrote:
> Hello
>
> Is it possible to have OpenBSD 7.2 automatically reboot after a kernel panic 
> happens?
>
> I tried setting: 
>
> ddb.panic=0
>
> but it does not reboot automatically.
> 
> As I am affected by the pfsync issue which leads to a kernel panic on OpenBSD 
> 7.2 so I would like the firewall to reboot as soon as this happens.

That is the only common way to do it (though on some machines
there's a supported hardware watchdog which would have a similar
effect), but of course you're at risk of fsck failures when
coming back after a panic.

You could run a snapshot instead..

reboot after kernel panic on 7.2

[mabi]

Hello

Is it possible to have OpenBSD 7.2 automatically reboot after a kernel panic 
happens?

I tried setting: 

ddb.panic=0

but it does not reboot automatically.

As I am affected by the pfsync issue which leads to a kernel panic on OpenBSD 
7.2 so I would like the firewall to reboot as soon as this happens.

Best,
Mabi

Re: How do I report a kernel panic occuring on install media?

[rtw0 dtw0]

Thanks for the tip!

So I’ll try another configuration with another install.

But so far I haven’t found any documentation about how to power off the
system - disabling acpi prevents system from shutting down.

Cheers

Le jeu. 14 avr. 2022 à 12:29, Stuart Henderson  a
écrit :

> On 2022/04/14 12:21, rtw0 dtw0 wrote:
> > Hi,
> >
> > To disable acpi permanently:
> > # config -ef /bsd
> > ukc > disable acpi
> > ukc > quit
>
> This is a REALLY BAD IDEA.
>
> From my earlier mail:
> https://marc.info/?l=openbsd-misc=164983204029245=2
>
> |  (Note: acpi drivers are used for various machine functions including
> |  in some cases temperature control, so it's not advisable to run with
> |  them disabled long term, but should be fine for a short test - the
> |  N2600 is low power too which helps).
>
>

Re: How do I report a kernel panic occuring on install media?

[Stuart Henderson]

On 2022/04/14 12:21, rtw0 dtw0 wrote:
> Hi,
> 
> To disable acpi permanently:
> # config -ef /bsd
> ukc > disable acpi
> ukc > quit

This is a REALLY BAD IDEA.

>From my earlier mail:  https://marc.info/?l=openbsd-misc=164983204029245=2

|  (Note: acpi drivers are used for various machine functions including
|  in some cases temperature control, so it's not advisable to run with
|  them disabled long term, but should be fine for a short test - the
|  N2600 is low power too which helps).

Re: How do I report a kernel panic occuring on install media?

[rtw0 dtw0]

Hi,

To disable acpi permanently:
# config -ef /bsd
ukc > disable acpi
ukc > quit

One thing I haven’t been able to do yet is get shutdown(8) to work with
acpi disabled, as it ends up rebooting automatically and -p or -h options
do not respond as they normally do.

acpi(4) explains that acpi is also responsible for powering off the machine.

/dev/apm might be an alternative for power management.

Anyone with a clue for shutting down the system with acpi disabled?

Cheers
Andy

Le mer. 13 avr. 2022 à 22:25,  a écrit :

> Thanks. Your email gave me hope.
> I thought it would never be possible to run OpenBSD on the hardware.
>
> > This is expected from the install kernel, it doesn't have DDB.
>
> This is important information. I think it would've been nice to see
> something about it on man pages, documentation, download page or
> somewhere noticable. I have a feeling there is something but I totally
> missed it.
>
> > Try boot -c at the boot loader prompt ... I would first try "disable
> > acpiec" and "quit" and see if that boots.
>
> This worked. Gave me a "UKC" prompt.
>
> boot> boot -c
> ...
> UKC> disable acpiec
> 257 acpiec* disabled
> UKC> quit
> ...
>
> Then it booted like usual to install-upgrade screen.
>
> > ...What's needed is a dump of the ACPI tables, which you could get
> > from another OS, but it would be helpful to try and get it booted into
> > OpenBSD as this could give more information.
>
> I don't know how to have a OpenBSD dual booting install so I tried once
> and then cancelled and then realized my whole HD was formatted!!! Even
> though I cancelled!!
>
> I tried installing to a flash drive and it didn't get detected (probably
> due to disabling acpiec). Then tried to install on the install media
> itself. It seemed to work.
>
> Wifi wouldn't turn on, so had to connect ethernet cable. Installed file
> sets from a mirror (I entered http, [enter], ftp.jaist.ac.jp, enter ...
> -x*, -game*, -comp* - in case someone else gets to this thread in
> future) since the install media doesn't have the file sets anymore and
> has been already formatted for the installation.
>
> It was getting hot when installing file sets. So I pointed a table fan
> at it just in case. :)
>
> After installing I rebooted and tried disabling acpiec first and it
> worked like before. I quickly got a dmesg and dmesg.boot.
>
> Then I tried booting again and again disabling one by one of these each
> time to see what happens:
>
> acpi0: boots
> acpitimer: boots into ddb prompt
> acpihpet: boots into ddb prompt
> acpiac: boots into ddb prompt
> acpibat: boots into ddb prompt
> acpibtn: boots into ddb prompt
> acpicpu: boots into ddb prompt
> acpicmos: boots into ddb prompt
> acpidock: boots into ddb prompt
> acpiec: boots
> acpimadt0: boots into ddb prompt
> acpimcfg: boots into ddb prompt
> acpiprt: boots into ddb prompt
> acpisbs: boots into ddb prompt
> acpitz: boots into ddb prompt
> acpiasus: boots into ddb prompt
> acpisony: boots into ddb prompt
> acpithinkpad: boots into ddb prompt
> acpitoshiba: boots into ddb prompt
> acpivideo: boots into ddb prompt
> acpivout: boots into ddb prompt
> acpipwrres: boots into ddb prompt
>
> For some reason ssh access is not working even though port 22 is open.
> I'll try to get the outputs and post it to @bugs. My email is
> also having trouble so don't know how soon I can post it.
>
> > CPU spec sheet says it could support it, but maybe it's disabled by
> > BIOS. IIRc 64-bit mode on some of the Atoms does not work
> > brilliantly anyway.
>
> Will check later.
>

Re: How do I report a kernel panic occuring on install media?

[ITwrx]

On 4/13/22 3:01 AM, misc.99...@aleeas.com wrote:

As far as I remember the CPU is only 32-bit capable. But outputs I gathered 
from Linux is telling me otherwise (given below).


i don't know enough about this cpu, so i'm going to bow out now. i just 
thought it was a simple accident. sorry if i sent you on a wild goose chase.

Re: How do I report a kernel panic occuring on install media?

[Stuart Henderson]

On 2022-04-13, misc.99...@aleeas.com  wrote:
> > It sounds like you're trying to use the 32bit OpenBSD installer for a
>> 64bit cpu. In that case, you would want the AMD64 installer.

Even if that is the case, it's not very likely to change the ACPI parsing.

> As far as I remember the CPU is only 32-bit capable. But outputs I gathered 
> from Linux is telling me otherwise (given below).

CPU spec sheet says it could support it, but maybe it's disabled by BIOS.
IIRc 64-bit mode on some of the Atoms does not work brilliantly anyway.

> To give it a shot, I just tried to boot amd64 install70.img (sha256: 
> 6bc7f945c2709247d449892c33c0f1b9a31590528572c1e988fef4a7637210e6) on the 
> machine and this time it didn't even get to kernel panic stage.
>
> Using drive 0, partition 3.
> Loading.
> probing: pc0 mem[634K 2035M a20=on]
> disk hd0+ hd1+*
>>> OpenBSD/amd64 BOOT 3.53
> boot>
> cannot open hd0a:/etc/random.seed: No such file or directory
> booting hd0a /7.0/amd64/bsd.rd: 3830471+1598464+3907256+0+704512 
> [109+288+28]=0x995530
> entry point at 0x81001000
>
> Then it stops. Pressing Ctrl+Alt+Del or any key doesn't do anything. Only way 
> is to press the power button to force shutdown.

The two main causes of this:

- booting on serial console without "set tty com0" in the boot loader
- trying to run amd64 on a machine that only supports 32-bit

Re: How do I report a kernel panic occuring on install media?

[Stuart Henderson]

On 2022-04-13, misc.99...@aleeas.com  wrote:
> I'm trying to boot OpenBSD 7.0 i386 image (sha256: 
> 2423307414df1800537063b3cafd9ae788b46711074b7f94d855c8a3de622f51) from a USB 
> flash drive on HP Mini, Intel Atom N2600 1.60 GHz machine. Before I could 
> install, unfortunately I'm facing a kernel panic. It shows on screen:
>
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU N2600 @ 1.60 GHz ("GenuineIntel" 686-class) 1.60 
> GHz, 06-36-01
> cpu0: 
> FPU,V86,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,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64 max=64. C-substates=0.2.2.0.2.0.3, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt0 at acpi0: bus 3 (PCI1)
> acpiprt0 at acpi0: bus 1 (RP01)
> acpiprt0 at acpi0: bus 2 (RP02)
> acpiec0 at acpi0
> Could not convert 1 to 0
>
> panic: aml_die aml_convert:2095
>
> The operating system has halted.
> Please press any key to reboot.
>
> Almost any key or key combination I press gets the machine to reboot.

This is expected from the install kernel, it doesn't have DDB.

> It runs Windows 7 and Debian just fine. In fact I rebooted on to the media 
> from a Debian install which is running without any hardware complaints. But 
> OpenBSD seems to have this issue.

OpenBSD has its own written-from-scratch ACPI implementation and can
sometimes run into problems interpreting machine ACPI tables that are
already handled by other implementations.

What's needed is a dump of the ACPI tables, which you could get from
another OS, but it would be helpful to try and get it booted into
OpenBSD as this could give more information.

Try boot -c at the boot loader prompt and disabling individual acpi
device drivers and see if you can get it booted like that. The i386
install kernel has these:

$ grep ^acpi RAMDISK_CD
acpi0   at bios?
acpihpet*   at acpi?
acpicmos*   at acpi?
acpiec* at acpi?
acpimadt0   at acpi?
acpiprt*at acpi?

So after "boot -c", I would first try "disable acpiec" and "quit" and
see if that boots. If not then try disabling others (acpiprt is probably
ok as you would likely have seen the error earlier).

If none work you can try "disable acpi" but information about *which*
driver hit the problem is likely to be helpful.

If you can get it installed then try to get it booted - you'll need
to disable the driver again to boot the standard kernel, and as this
has additional acpi drivers, potentially you may need to disable some
others - here's the list in case you do run into it:

$ grep ^acpi GENERIC
acpi0   at bios?
acpitimer*  at acpi?
acpihpet*   at acpi?
acpiac* at acpi?
acpibat*at acpi?
acpibtn*at acpi?
acpicpu*at acpi?
acpicmos*   at acpi?
acpidock*   at acpi?
acpiec* at acpi?
acpimadt0   at acpi?
acpimcfg*   at acpi?
acpiprt*at acpi?
acpisbs*at acpi?
acpitz* at acpi?
acpiasus*   at acpi?
acpisony*   at acpi?
acpithinkpad*   at acpi?
acpitoshiba*at acpi?
acpivideo*  at acpi?
acpivout*   at acpivideo?
acpipwrres* at acpi?

If you can get it booted then run sendbug to generate a report (usually
easiest as "sendbug -P > somefile" and move it to a machine which
already has email configured; scp or copy via USB storage etc).
Send that in to b...@openbsd.org along with details of which driver/s
you disabled, and the kernel output you included in your mail above.

(Note: acpi drivers are used for various machine functions including
in some cases temperature control, so it's not advisable to run with
them disabled long term, but should be fine for a short test - the
N2600 is low power too which helps).

-- 
Please keep replies on the mailing list.

Re: How do I report a kernel panic occuring on install media?

[ITwrx]

On 4/12/22 9:39 PM, misc.99...@aleeas.com wrote:

I'm trying to boot OpenBSD 7.0 i386 image (sha256: 
2423307414df1800537063b3cafd9ae788b46711074b7f94d855c8a3de622f51) from a USB 
flash drive on HP Mini, Intel Atom N2600 1.60 GHz machine


It sounds like you're trying to use the 32bit OpenBSD installer for a 
64bit cpu. In that case, you would want the AMD64 installer.

Re: snapshot kernel panic related to radeondrm missing firmware

[Jonathan Gray]

On Wed, Jan 13, 2021 at 04:10:46AM +0200, Mihai Popescu wrote:
> I took the chance and installed from a recent snapshot - 12.01.2021. I got
> a kernel panic at first boot after install, related to missing firmware for
> radeondrm.
> I disabled the radeondrm then the boot process was fine and I installed
> radeondrm firmware by hand. At the next boot everything was fine again.
> 
> My question: is this known, maybe related to the recent changes in compiler
> stuff?
> The short message is panic: vfree, non vmalloced addr 0x0. My keyboard is
> not responsive, so if the info is necessary, then i need to use another
> computer to capture all on serial.
> Is it needed? Should i be patient for the next snapshot? Last good known
> snapshot kernel was 03.01.2021.

This should be resolved by future snapshots as I just reverted the
vmalloc changes for unrelated reasons.

Normally when radeondrm can't find firmware it will detach and vga or
efifb will take over the console.

Thanks for the report.

snapshot kernel panic related to radeondrm missing firmware

[Mihai Popescu]

I took the chance and installed from a recent snapshot - 12.01.2021. I got
a kernel panic at first boot after install, related to missing firmware for
radeondrm.
I disabled the radeondrm then the boot process was fine and I installed
radeondrm firmware by hand. At the next boot everything was fine again.

My question: is this known, maybe related to the recent changes in compiler
stuff?
The short message is panic: vfree, non vmalloced addr 0x0. My keyboard is
not responsive, so if the info is necessary, then i need to use another
computer to capture all on serial.
Is it needed? Should i be patient for the next snapshot? Last good known
snapshot kernel was 03.01.2021.


Thank you.

Re: Kernel panic probably linked to inteldrm

[Jérôme FRGACIC]

Ok, after further investigations, my problem does not seems to be linked 
with inteldrm. The kernel panic seems to happen randomly with or without 
inteldrm enabled.


Nevertheless, if I disable inteldrm, I can access ddb when the panic 
happen (I don't know why, BTW) and I get this.


kernel: double fault trap, code=0
Stopped at restore_saved+0x1e: xorq 0x30(%rsp),%r11

I have no stack trace with the ???trace??? command and the command ???show 
panic??? tells me that the kernel do not panic (which is... strange?). If 
I correctly look at the kernel sources, restore_saved seems to be called 
by cpu_switchto which is responsible to switch processes between the 
different processors.


Any idea about this problem?

Kernel panic probably linked to inteldrm

[Jérôme FRGACIC]

Hi misc@,

I have installed OpenBSD 6.7 on a new laptop and I experiment regular 
kernel panic. Unfortunately, I lack of information because ddb doesn't 
start when it happens.


After some researches and tests, I've disabled inteldrm at kernel level 
and since I don't experience any kernel panic. So, I suppose this is 
linked, but since the behaviour seems to be random I'm not 100% sure.


Is there any way to get more information when a kernel panic happen and 
ddb doesn't start? I see nothing in /var/log/messages nor 
/var/log/Xorg.0.log nor dmesg... And can I try something else in order 
to fix this issue with inteldrm?


I have an Intel UHD Graphics « card ».

I put below the output of dmesg, pcidump -v and Xorg.0.log, if it can help.

Thanks in adavance.

Kind regards,


Jérôme FRGACIC

$ dmesg
OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8384339968 (7995MB)
avail mem = 8117616640 (7741MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x97265000 (56 entries)
bios0: vendor INSYDE Corp. version "1.07.05" date 10/24/2019
bios0: Notebook NJ50_70CU
acpi0 at bios0: ACPI 5.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT LPIT WSMT SSDT DBGP DBG2 SSDT 
SSDT NHLT HPET APIC MCFG SSDT FPDT BGRT
acpi0: wakeup devices XHC_(S3) HDAS(S4) RP01(S3) PXSX(S4) RP02(S3) 
PXSX(S4) RP03(S3) PXSX(S4) RP04(S3) PXSX(S4) RP05(S3) PXSX(S4) RP06(S3) 
PXSX(S4) RP07(S3) 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) i3-10110U CPU @ 2.10GHz, 15439.45 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,VMX,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,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) i3-10110U CPU @ 2.10GHz, 3691.42 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,VMX,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz, 3691.40 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,VMX,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-10110U CPU @ 2.10GHz, 3691.41 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,VMX,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08

video: kernel panic

[Claudio Correa]

Hello,

any of the list members came across a kernel panic caused by running
/usr/X11R6/bin/video ?

$ video

fatal protection fault in supervisor mode
http://155.138.134.219/videokernelcrash.jpg

OpenBSD 6.7-current (GENERIC.MP) #204: Thu May 21 11:44:48 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8334811136 (7948MB)
avail mem = 8069582848 (7695MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeac50 (96 entries)
bios0: vendor Dell Inc. version "1.13.0" date 11/18/2019
bios0: Dell Inc. Vostro 5471
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT HPET
SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT
SSDT TPM2 SSDT ASF! DMAR BGRT acpi0: wakeup devices RP09(S4) PXSX(S4)
RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4)
RP01(S4) PEGP(S4) PEGA(S4) RP02(S4) PXSX(S4) RP03(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)
Core(TM) i7-8550U CPU @ 1.80GHz, 1896.21 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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-8550U CPU @ 1.80GHz, 1895.59 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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-8550U CPU @ 1.80GHz, 1895.59 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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-8550U CPU @ 1.80GHz, 1895.59 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus 1 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)
acpiprt11 at acpi0: bus -1 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus 2 (RP05)
acpiprt14 at acpi0: bus 3 (RP06)
acpiprt15 at acpi0: bus -1 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)

Kernel panic during install 6.6

[Chris Zakelj]

Been a long time since I've written, but I've been reading (almost) all
along, and it was that troll thread two months ago that keyed me into
the fact that my email preferences were NOT being obeyed, and started
the wheels grinding.  In trying to set up a new system to begin knocking
off 15 years of rust and starting to learn something new, I'm pulling a
PowerEdge SC1435 out of the closet, then promptly getting a kernel panic
from both install66.fs and install66.iso.  Memory seems to check out,
suspected cause is the Areca ARC-1200 RAID controller since that's where
the boot process fails, but that's about all I can give apart from the
drives behind the controller being a pair of Seagate 3TB ST3000DM001
drives configured as RAID-1 with 64bit LBA addressing, and that the
keyboard is unresponsive (so no ps/trace) except for CTRL-A rebooting
the system. I haven't tried 4k blocks yet, figured I'd ask first before
beginning the array re-initialization process.  Bootloader and dmesg
follows:

CD-ROM: 82
Loading /6.6/AMD64/CDBOOT
probing: pc0 com0 mem[640K 3581M 12800M a20=on]
disk: hd0+* cd0
>> OpenBSD/amd64 CDBOOT 3.44
boot> set tty com0
switching console to com0
cannot open cd0a:/etc/random.seed: No such file or directory
booting cd0a:/6.6/amd64/bsd.rd: 3732171+1537024+3885432+0+598016
[376562+128+455544+303577]=0xa648d0
entry point at 0x81001000
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved. 
https://www.OpenBSD.org

OpenBSD 6.6 (RAMDISK_CD) #349: Sat Oct 12 11:03:52 MDT 2019
    dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 17161854976 (16366MB)
avail mem = 16637759488 (15867MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xdffbc000 (50 entries)
bios0: vendor Dell Inc. version "2.2.5" date 03/21/2008
bios0: Dell Inc. PowerEdge SC1435
acpi0 at bios0: ACPI 3.0
acpi0: tables DSDT FACP APIC SPCR HPET MCFG SLIC ERST HEST BERT EINJ
SRAT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Dual-Core AMD Opteron(tm) Processor 2212, 1995.35 MHz, 0f-41-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,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAP8
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
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
cpu0: apic clock running at 199MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 16 pins, remapped
ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 11, 16 pins, remapped
ioapic2 at mainbus0: apid 6 pa 0xfec02000, version 11, 16 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (PXB_)
acpiprt2 at acpi0: bus 4 (PPBX)
acpiprt3 at acpi0: bus 5 (EXB0)
acpiprt4 at acpi0: bus 1 (EXB1)
acpiprt5 at acpi0: bus 2 (EXB2)
acpiprt6 at acpi0: bus 6 (EXB3)
acpiprt7 at acpi0: bus 7 (EXB4)
acpicpu at acpi0 not configured
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
pci0 at mainbus0 bus 0
ppb0 at pci0 dev 1 function 0 "ServerWorks HT-1000 PCI" rev 0x00
pci1 at ppb0 bus 3
ppb1 at pci1 dev 13 function 0 "ServerWorks HT-1000 PCIX" rev 0xc0
pci2 at ppb1 bus 4
pchb0 at pci0 dev 2 function 0 "ServerWorks HT-1000" rev 0x00
"ServerWorks HT-1000 LPC" rev 0x00 at pci0 dev 2 function 2 not configured
ohci0 at pci0 dev 3 function 0 "ServerWorks HT-1000 USB" rev 0x01: apic
4 int 15, version 1.0, legacy support
ohci1 at pci0 dev 3 function 1 "ServerWorks HT-1000 USB" rev 0x01: apic
4 int 15, version 1.0, legacy support
ehci0 at pci0 dev 3 function 2 "ServerWorks HT-1000 USB" rev 0x01: apic
4 int 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "ServerWorks EHCI root hub"
rev 2.00/1.00 addr 1
vga1 at pci0 dev 4 function 0 "ATI ES1000" rev 0x02
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
ppb2 at pci0 dev 7 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2
pci3 at ppb2 bus 5
ppb3 at pci0 dev 8 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2
pci4 at ppb3 bus 1
bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1
(0x4201): msi, address 00:18:8b:75:37:ad
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb4 at pci0 dev 9 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2
pci5 at ppb4 bus 2
ppb5 at pci0 dev 10 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2: msi
pci6 at ppb5 bus 6
arc0 at pci6 dev 0 function 0 "Areca ARC-1200B" rev 0x00: apic 5 int 3
uvm_fault(0x81910b70, 0x10, 0, 1)

Re: ppppoe octeon kernel panic .6.6

[Holger Glaess]

hi


with the current version


OpenBSD 6.6-current (GENERIC.MP) #48: Tue Dec 10 16:30:01 MST 2019
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP


the pppoe interface works as expected. no kernel panic anymore


thanks

holger

Am 22.10.19 um 21:12 schrieb Holger Glaess:

hi

ii will try tomorrow to do an backtrace after the panic.

i there additonal thinks what i can , or just this described in

https://www.openbsd.org/ddb.html

?


Holger


Am 22.10.19 um 07:10 schrieb Peter J. Philipp:

Hi,

The mail from Holger Glaess seems to be missing a backtrace.  I got 
one, but
I have very little time today and tomorrow to debug anything, I have 
put a
temporary replacement for the octeon pppoe router at my premises for 
the time

being.

Also, I tried poking around in sppp_auth_send() in 
/sys/net/if_spppsubr.c but
to no avail.  The fault lies in bcopy() in that function.  In the 
backtrace
it shows up as smallcpy().  When pppoe0 is disabled the kernel 
doesn't panic.


My bt follows with dmesg from my machine that was upgraded to 6.6.
After that Holger Glaess's mail which I had to fish out of my trash as I
had accidentally deleted it.

saturn# cu -l /dev/cuaU0 -s 115200
Connected to /dev/cuaU0 (speed 115200)
btint
smallcpy+0x8 (1,980001b6e376,1,2)  ra 0x8125140c sp 
0x98000ffdb

9b8, sz 0
sppp_auth_send+0x10c (1,980001b6e376,1,2)  ra 0x8124d294 
sp 0x98000

ffdb9b8, sz 144
sppp_lcp_tlu+0x274 (1,980001b6e376,1,2)  ra 0x81246f64 sp 
0x980

00ffdba48, sz 128
sppp_cp_input+0x141c (1,980001b6e376,1,2)  ra 0x81245458 
sp 0x98000

ffdbac8, sz 112
sppp_input+0x1d0 (1,980001b6e376,1,2)  ra 0x810b5e74 sp 
0x98000

ffdbb38, sz 80
pppoeintr+0xf9c (1,980001b6e376,1,2)  ra 0x813572c8 sp 
0x98000f

fdbb88, sz 400
if_netisr+0x118 (1,980001b6e376,1,2)  ra 0x8145d48c sp 
0x98000f

fdbd18, sz 80
taskq_thread+0x54 (1,980001b6e376,1,2)  ra 0x8127a0ec sp 
0x9800

0ffdbd68, sz 80
proc_trampoline+0x1c (1,980001b6e376,1,2)  ra 0x0 sp 
0x98000ffdbdb8, sz

  0
User-level: pid 81393
ddb{1}> show panic
the kernel did not panic
ddb{1}> boot reboot
System restart.
Jumping to start of image at address 0xbfca


U-Boot 2012.04.01 (UBNT Build ID: 4605996-gd120a44) (Build time: Oct 
14 2013 - 18:14:14)


Skipping PCIe port 0 BIST, in EP mode, can't tell if clocked.
Skipping PCIe port 1 BIST, reset not done. (port not configured)
BIST check passed.
UBNT_E200 r1:1, r2:9, serial #: 24A43C069F12
Core clock: 800 MHz, IO clock: 600 MHz, DDR clock: 533 MHz (1066 Mhz 
DDR)

Base DRAM address used by u-boot: 0x8f80, size: 0x80
DRAM: 2 GiB
Clearing DRAM.. done
Flash: 8 MiB
Net:   octeth0, octeth1, octeth2, octeth3, octeth4, octeth5, octeth6, 
octeth7

MMC:   Octeon MMC/SD0: 0
USB:   USB EHCI 1.00
scanning bus for devices... cannot reset port 1!?
1 USB Device(s) found
Type the command 'usb start' to scan for USB storage devices.

Hit any key to stop autoboot:  0
reading boot

3122300 bytes read
argv[2]: numcores=2
Allocating memory for ELF segment: addr: 0x8200 (adjusted 
to: 0x200), size 0x330d50
## Loading big-endian Linux kernel with entry point: 
0x8200 ...

Bootloader: Done loading app on coremask: 0x3
Starting cores 0x3
bootmem desc 0x48108 version 3.0
avail phys mem 0x001004d0 - 0x01fffbc0
skipped
avail phys mem 0x02330d50 - 0x0f10
avail phys mem 0x0f100020 - 0x0f100080
avail phys mem 0x0f1000a0 - 0x0fffd700
avail phys mem 0x2000 - 0x8f80
Total DRAM Size 0x8000
mem_layout[0] page 0x08CD -> 0x3C40
mem_layout[1] page 0x3C41 -> 
0x3FF)+"ij}"}Rj$}"}R$}}Rj$}B}Rj$}B}Rj$}
Rj$}2ij}}{j}"}R$Rj$}"}}Rj$}*R$}}}R$}}}Rj$}$}R}}Rj$2}{j$}R$}Rj$}}j}}RR}Rj$}"}{j}Copyright989, 
1991, 1egents of the y of Califhtorg


OpenBSD 6.6 (BOOT) #97: Sat Oct 12 06:00:20 MDT 2019
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/BOOT
real mem = 2147483648 (2048MB)
avail mem = 2083438592 (1986MB)
mainbus0 at root: board 20003 rev 1.9
cpu0 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
cpu0: cache L1-I 37KB 37 way D 32KB 32 way, L2 1024KB 8 way
clock0 at mainbus0: int 5
iobus0 at mainbus0
simplebus0 at iobus0: "soc"
octciu0 at simplebus0
"gpio-controller" at simplebus0 not configured
"mdio" at simplebus0 not configured
"mdio" at simplebus0 not configured
"pip" at simplebus0 not configured
"i2c" at simplebus0 not configured
"i2c" at simplebus0 not configured
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
com1 at simplebus0: ns16550a, 64 byte fifo
com1: probed fifo depth: 0 bytes
"spi" at simplebus0 not configured
octmmc0 at simplebus0
sdmmc0 at octmmc0: 8-bit, 

Re: ppppoe octeon kernel panic .6.6

[Peter J. Philipp]

On Wed, Oct 23, 2019 at 08:21:50AM +0200, Holger Glaess wrote:
> hi
> 
> 
> here the traceback , i hope ;)

Hi Holger & Tech,

I have made my octeon router work again and I have a patch.  But I'm not an
openbsd developer, nor is this patch official in any way.  It was a lot of
debugging and refactoring I had to do in /sys/net/if_spppsubr.c because
the varargs were really screwy.  size_t is not a standard builtin vararg
I believe and there was some sideffects with that.  I also applied a header
include for strlen() in this patch.

This patch should be CC'ed to tech@ and they can disect it and use it for
hints.  I have not tested this patch on any arch other than octeon.  In the
end it was not time wasted I spent 2 mornings and 2 nights on this.

You should be OK extracing sys.tar.gz in your octeon and build a kernel like
the normal way.  I know the octeons are usually low on diskspace.

Best Regards,
-peter


--- if_spppsubr.c.orig  Tue Oct 22 18:49:47 2019
+++ if_spppsubr.c   Wed Oct 23 08:03:35 2019
@@ -64,6 +64,7 @@
 #endif
 
 #include 
+#include 
 
 # define UNTIMEOUT(fun, arg, handle)   \
timeout_del(&(handle))
@@ -233,7 +234,7 @@
 int newstate);
 void sppp_auth_send(const struct cp *cp,
   struct sppp *sp, unsigned int type, u_int id,
-  ...);
+   u_int bitmask, ...);
 
 void sppp_up_event(const struct cp *cp, struct sppp *sp);
 void sppp_down_event(const struct cp *cp, struct sppp *sp);
@@ -3277,7 +3278,8 @@
STDDCL;
struct lcp_header *h;
int len, x;
-   u_char *value, *name, digest[AUTHCHALEN], dsize;
+   u_char *value, *name, digest[AUTHCHALEN];
+   int dsize;
int value_len, name_len;
MD5_CTX ctx;
 
@@ -3335,8 +3337,8 @@
MD5Final(digest, );
dsize = sizeof digest;
 
-   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident,
-  sizeof dsize, (const char *),
+   sppp_auth_send(, sp, CHAP_RESPONSE, h->ident, 0x1,
+  1, dsize,
   sizeof digest, digest,
   strlen(sp->myauth.name),
   sp->myauth.name,
@@ -3458,7 +3460,7 @@
if (value_len != sizeof digest ||
timingsafe_bcmp(digest, value, value_len) != 0) {
/* action scn, tld */
-   sppp_auth_send(, sp, CHAP_FAILURE, h->ident,
+   sppp_auth_send(, sp, CHAP_FAILURE, h->ident, 0, 
   sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
   0);
chap.tld(sp);
@@ -3467,7 +3469,7 @@
/* action sca, perhaps tlu */
if (sp->state[IDX_CHAP] == STATE_REQ_SENT ||
sp->state[IDX_CHAP] == STATE_OPENED)
-   sppp_auth_send(, sp, CHAP_SUCCESS, h->ident,
+   sppp_auth_send(, sp, CHAP_SUCCESS, h->ident, 0,
   sizeof(SUCCMSG) - 1, (u_char *)SUCCMSG,
   0);
if (sp->state[IDX_CHAP] == STATE_REQ_SENT) {
@@ -3634,7 +3636,7 @@
 void
 sppp_chap_scr(struct sppp *sp)
 {
-   u_char clen;
+   int clen;
 
/* Compute random challenge. */
arc4random_buf(sp->chap_challenge, sizeof(sp->chap_challenge));
@@ -3642,8 +3644,8 @@
 
sp->confid[IDX_CHAP] = ++sp->pp_seq;
 
-   sppp_auth_send(, sp, CHAP_CHALLENGE, sp->confid[IDX_CHAP],
-  sizeof clen, (const char *),
+   sppp_auth_send(, sp, CHAP_CHALLENGE, sp->confid[IDX_CHAP], 0x1,
+  1, clen,
   (size_t)AUTHCHALEN, sp->chap_challenge,
   strlen(sp->myauth.name),
   sp->myauth.name,
@@ -3671,7 +3673,8 @@
STDDCL;
struct lcp_header *h;
int len, x;
-   u_char *name, *passwd, mlen;
+   u_char *name, *passwd;
+   int mlen;
int name_len, passwd_len;
 
len = m->m_pkthdr.len;
@@ -3724,7 +3727,8 @@
/* action scn, tld */
mlen = sizeof(FAILMSG) - 1;
sppp_auth_send(, sp, PAP_NAK, h->ident,
-  sizeof mlen, (const char *),
+  0x1,
+  1, mlen,
   sizeof(FAILMSG) - 1, (u_char *)FAILMSG,
   0);
pap.tld(sp);
@@ -3735,7 +3739,8 @@
sp->state[IDX_PAP] == STATE_OPENED) {
mlen = sizeof(SUCCMSG) - 1;
sppp_auth_send(, sp, PAP_ACK, h->ident,
-  sizeof mlen, (const char *),
+  

Re: ppppoe octeon kernel panic .6.6

[Holger Glaess]

3C40
mem_layout[3] page 0x3C41 -> 0x3FFFInitial 
setup done, switching console.

boot_desc->desc_ver:7
boot_desc->desc_size:400
boot_desc->stack_top:0
boot_desc->heap_start:0
boot_desc->heap_end:0
boot_desc->argc:2
boot_desc->flags:0x5
boot_desc->core_mask:0x3
boot_desc->dram_size:2048
boot_desc->phy_mem_desc_addr:0
boot_desc->debugger_flag_addr:0xc84
boot_desc->eclock:8
boot_desc->boot_info_addr:0x100200
boot_info->ver_major:1
boot_info->ver_minor:3
boot_info->stack_top:0
boot_info->heap_start:0
boot_info->heap_end:0
boot_info->boot_desc_addr:0
boot_info->exception_base_addr:0x1000
boot_info->stack_size:0
boot_info->flags:0x5
boot_info->core_mask:0x3
boot_info->dram_size:2048
boot_info->phys_mem_desc_addr:0x48108
boot_info->debugger_flags_addr:0
boot_info->eclock:8
boot_info->dclock:53300
boot_info->board_type:20003
boot_info->board_rev_major:1
boot_info->board_rev_minor:9
boot_info->mac_addr_count:8
boot_info->cf_common_addr:0
boot_info->cf_attr_addr:0
boot_info->led_display_addr:0
boot_info->dfaclock:0
boot_info->config_flags:0x8
boot_info->fdt_addr:0x8
[ using 574056 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved. 
https://www.OpenBSD.org


OpenBSD 6.6 (GENERIC.MP) #107: Sat Oct 12 07:30:17 MDT 2019
dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
real mem = 2147483648 (2048MB)
avail mem = 2096054272 (1998MB)
mainbus0 at root: board 20003 rev 1.9
cpu0 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
cpu0: cache L1-I 37KB 37 way D 32KB 32 way, L2 1024KB 8 way
cpu1 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
cpu1: cache L1-I 37KB 37 way D 32KB 32 way, L2 1024KB 8 way
clock0 at mainbus0: int 5
octcrypto0 at mainbus0
iobus0 at mainbus0
simplebus0 at iobus0: "soc"
octciu0 at simplebus0
octgpio0 at simplebus0: 20 pins, xbit 16
octsmi0 at simplebus0
octsmi1 at simplebus0
octpip0 at simplebus0
octgmx0 at octpip0 interface 0
cnmac0 at octgmx0: SGMII, address 24:a4:3c:06:9f:12
ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

cnmac1 at octgmx0: SGMII, address 24:a4:3c:06:9f:13
ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

cnmac2 at octgmx0: SGMII, address 24:a4:3c:06:9f:14
ukphy2 at cnmac2 phy 6: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

cnmac3 at octgmx0: SGMII, address 24:a4:3c:06:9f:15
ukphy3 at cnmac3 phy 7: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

octgmx1 at octpip0 interface 1
cnmac4 at octgmx1: SGMII, address 24:a4:3c:06:9f:16
ukphy4 at cnmac4 phy 0: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

cnmac5 at octgmx1: SGMII, address 24:a4:3c:06:9f:17
ukphy5 at cnmac5 phy 1: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

cnmac6 at octgmx1: SGMII, address 24:a4:3c:06:9f:18
ukphy6 at cnmac6 phy 2: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

cnmac7 at octgmx1: SGMII, address 24:a4:3c:06:9f:19
ukphy7 at cnmac7 phy 3: Generic IEEE 802.3u media interface, rev. 3: 
OUI 0x180361, model 0x0004

"i2c" at simplebus0 not configured
"i2c" at simplebus0 not configured
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
com1 at simplebus0: ns16550a, 64 byte fifo
com1: probed fifo depth: 0 bytes
"spi" at simplebus0 not configured
octmmc0 at simplebus0
sdmmc0 at octmmc0: 8-bit, mmc high-speed
"bootbus" at simplebus0 not configured
"dma-engine" at simplebus0 not configured
"dma-engine" at simplebus0 not configured
octuctl0 at simplebus0
ehci0 at octuctl0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon EHCI root hub" rev 
2.00/1.00 addr 1

ohci0 at octuctl0, version 1.0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Octeon OHCI root hub" rev 
1.00/1.00 addr 1

octrng0 at iobus0 base 0x14000 irq 0
octpcie0 at iobus0: 2 ports
octpcie0 port 1: reset timeout
uhidev0 at uhub1 port 1 configuration 1 interface 0 "American Power 
Conversion Back-UPS CS 650 FW:817.v9.I USB FW:v9" rev 1.10/0.06 addr 2

uhidev0: iclass 3/0, 98 report ids
upd0 at uhidev0
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable
sd0: 3776MB, 512 bytes/sector, 7733248 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (b3a80208ecd8c82c.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!
Ent

Re: ppppoe octeon kernel panic .6.6

[Holger Glaess]

lebus0: ns16550a, 64 byte fifo
com0: console
com1 at simplebus0: ns16550a, 64 byte fifo
com1: probed fifo depth: 0 bytes
"spi" at simplebus0 not configured
octmmc0 at simplebus0
sdmmc0 at octmmc0: 8-bit, mmc high-speed
"bootbus" at simplebus0 not configured
"dma-engine" at simplebus0 not configured
"dma-engine" at simplebus0 not configured
octuctl0 at simplebus0
ehci0 at octuctl0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon EHCI root hub" rev 2.00/1.00 
addr 1
ohci0 at octuctl0, version 1.0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Octeon OHCI root hub" rev 1.00/1.00 
addr 1
octrng0 at iobus0 base 0x14000 irq 0
octpcie0 at iobus0: 2 ports
octpcie0 port 1: reset timeout
uhidev0 at uhub1 port 1 configuration 1 interface 0 "American Power Conversion 
Back-UPS CS 650 FW:817.v9.I USB FW:v9" rev 1.10/0.06 addr 2
uhidev0: iclass 3/0, 98 report ids
upd0 at uhidev0
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable
sd0: 3776MB, 512 bytes/sector, 7733248 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (b3a80208ecd8c82c.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!
Enter pathname of shell or RETURN for sh:


 Forwarded Message 
Subject:oe octeon kernel panic .6.6
Date:   Sun, 20 Oct 2019 10:33:12 +0200
From:   Holger Glaess 
To: misc@openbsd.org



hi


if i boot my edgerouter with connected dsl modem i get an kernel panic.


reordering libraries:
Trap cause = 2 Frame 0x98004efcb860
Trap PC 0x813cc38c RA 0x8109feac fault 0x0
0x813cc2d8 (1,98000f991b76,1,2)?? ra 0x8109feac sp
0x98004efcb9b8, sz 0
0x8109fda0 (1,98000f991b76,1,2)?? ra 0x8109bd34 sp
0x98004efcb9b8, sz 144
0x8109bac0 (1,98000f991b76,1,2)?? ra 0x81095a04 sp
0x98004efcba48, sz 128
0x81095240 (1,98000f991b76,1,2)?? ra 0x0 sp 0x98004efcbac8, sz
0
User-level: pid 98161
stopped on non ddb fault
Stopped at?? 0x813cc38c: lbu v1,0(a0)
ddb{0}> boot reboot
System restart.


in my atom box with 6.5 , the same configuration for the pppoe device , the
system boot and run well.

this problem at the octeon system i got also with 6.5 .

configs are

at the octeon replace?? the interface re3 to cnmac3


/etc 23>cat hostname.re3
rdomain 40
mtu 1518
inet 192.168.1.250 255.255.255.0 NONE
up


/etc 25>cat hostname.vlan7
mtu 1508
rdomain 40
parent re3 vnetid 7
up

/etc 26>cat hostname.pppoe0
!echo "add to rdomain 40"
rdomain 40
rtlabel netcologne
!echo "set startup ip"
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
pppoedev vlan7 authproto pap \
authname 'x@y' authkey 'abc123' up
dest 0.0.0.1
!echo "enable ipv6"
inet6 autoconf autoconfprivacy
!/sbin/route -n -T 40 add default -ifp pppoe0 0.0.0.1
!/sbin/route -n -T 40 add -inet6 default -ifp pppoe0 fe80::%pppoe0


howto fix this ?


holger

- End forwarded message -

ppppoe octeon kernel panic .6.6

[Peter J. Philipp]

 high-speed
"bootbus" at simplebus0 not configured
"dma-engine" at simplebus0 not configured
"dma-engine" at simplebus0 not configured
octuctl0 at simplebus0
ehci0 at octuctl0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon EHCI root hub" rev 2.00/1.00 
addr 1
ohci0 at octuctl0, version 1.0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Octeon OHCI root hub" rev 1.00/1.00 
addr 1
octrng0 at iobus0 base 0x14000 irq 0
octpcie0 at iobus0: 2 ports
octpcie0 port 1: reset timeout
uhidev0 at uhub1 port 1 configuration 1 interface 0 "American Power Conversion 
Back-UPS CS 650 FW:817.v9.I USB FW:v9" rev 1.10/0.06 addr 2
uhidev0: iclass 3/0, 98 report ids
upd0 at uhidev0
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable
sd0: 3776MB, 512 bytes/sector, 7733248 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (b3a80208ecd8c82c.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!
Enter pathname of shell or RETURN for sh:


 Forwarded Message 
Subject:oe octeon kernel panic .6.6
Date:   Sun, 20 Oct 2019 10:33:12 +0200
From:   Holger Glaess 
To: misc@openbsd.org



hi


if i boot my edgerouter with connected dsl modem i get an kernel panic.


reordering libraries:
Trap cause = 2 Frame 0x98004efcb860
Trap PC 0x813cc38c RA 0x8109feac fault 0x0
0x813cc2d8 (1,98000f991b76,1,2)?? ra 0x8109feac sp
0x98004efcb9b8, sz 0
0x8109fda0 (1,98000f991b76,1,2)?? ra 0x8109bd34 sp
0x98004efcb9b8, sz 144
0x8109bac0 (1,98000f991b76,1,2)?? ra 0x81095a04 sp
0x98004efcba48, sz 128
0x81095240 (1,98000f991b76,1,2)?? ra 0x0 sp 0x98004efcbac8, sz
0
User-level: pid 98161
stopped on non ddb fault
Stopped at?? 0x813cc38c: lbu v1,0(a0)
ddb{0}> boot reboot
System restart.


in my atom box with 6.5 , the same configuration for the pppoe device , the
system boot and run well.

this problem at the octeon system i got also with 6.5 .

configs are

at the octeon replace?? the interface re3 to cnmac3


/etc 23>cat hostname.re3
rdomain 40
mtu 1518
inet 192.168.1.250 255.255.255.0 NONE
up


/etc 25>cat hostname.vlan7
mtu 1508
rdomain 40
parent re3 vnetid 7
up

/etc 26>cat hostname.pppoe0
!echo "add to rdomain 40"
rdomain 40
rtlabel netcologne
!echo "set startup ip"
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
pppoedev vlan7 authproto pap \
authname 'x@y' authkey 'abc123' up
dest 0.0.0.1
!echo "enable ipv6"
inet6 autoconf autoconfprivacy
!/sbin/route -n -T 40 add default -ifp pppoe0 0.0.0.1
!/sbin/route -n -T 40 add -inet6 default -ifp pppoe0 fe80::%pppoe0


howto fix this ?


holger

- End forwarded message -

ppppoe octeon kernel panic .6.6

[Holger Glaess]

hi


if i boot my edgerouter with connected dsl modem i get an kernel panic.


reordering libraries:
Trap cause = 2 Frame 0x98004efcb860
Trap PC 0x813cc38c RA 0x8109feac fault 0x0
0x813cc2d8 (1,98000f991b76,1,2)  ra 0x8109feac sp 
0x98004efcb9b8, sz 0
0x8109fda0 (1,98000f991b76,1,2)  ra 0x8109bd34 sp 
0x98004efcb9b8, sz 144
0x8109bac0 (1,98000f991b76,1,2)  ra 0x81095a04 sp 
0x98004efcba48, sz 128
0x81095240 (1,98000f991b76,1,2)  ra 0x0 sp 
0x98004efcbac8, sz 0

User-level: pid 98161
stopped on non ddb fault
Stopped at  0x813cc38c: lbu v1,0(a0)
ddb{0}> boot reboot
System restart.


in my atom box with 6.5 , the same configuration for the pppoe device , 
the system boot and run well.


this problem at the octeon system i got also with 6.5 .

configs are

at the octeon replace  the interface re3 to cnmac3


/etc 23>cat hostname.re3
rdomain 40
mtu 1518
inet 192.168.1.250 255.255.255.0 NONE
up


/etc 25>cat hostname.vlan7
mtu 1508
rdomain 40
parent re3 vnetid 7
up

/etc 26>cat hostname.pppoe0
!echo "add to rdomain 40"
rdomain 40
rtlabel netcologne
!echo "set startup ip"
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
pppoedev vlan7 authproto pap \
authname 'x@y' authkey 'abc123' up
dest 0.0.0.1
!echo "enable ipv6"
inet6 autoconf autoconfprivacy
!/sbin/route -n -T 40 add default -ifp pppoe0 0.0.0.1
!/sbin/route -n -T 40 add -inet6 default -ifp pppoe0 fe80::%pppoe0


howto fix this ?


holger

Re: Strange kernel panic-like problem

[Otto Moerbeek]

On Thu, Feb 07, 2019 at 11:18:40PM -0600, Kyle wrote:

> I recently upgraded a box running 6.2 to 6.4 via clean install. After a few 
> days of running normally it started locking up, usually within a minute or so 
> after booting up to the login prompt. ddb appears on the console.
> 
> I eventually thought to try booting bsd.sp, which has been running for about 
> a day now without locking up.
> 
> Any clues to point me in the right direction would be much appreciated.
> 
> Here's some excerpts from the serial console (different sessions) and a dmesg:
> 
> 
> ddb{0}> show panic
> the kernel did not panic
> ddb{0}> trace
> acpicpu_idle() at acpicpu_idle+0x1ea
> sched_idle(0) at sched_idle+0x245
> end trace frame: 0x0, count: -2
> 
> 
> 
> login: NMI ... going o debugger

NMIs (Non Maskable Interrupts) are often an indication of hardware problems.

-Otto

> ddb{0}䀿   movq$0x8,%rcxuaei[1;24r c
>db{}> 
> ddb{0}> 
> d{0}> 
> ddb{0} 
> ddb{0}> 
> ddb{0}> 
> ddb{�}> 
> ddb{0> 
> db{0}> show panic
> the kernel did not panic
> ddb{0}> 
> the kernel did not panic
> ddb{0}> 
> the kernel did not panic
> ddb{0}> 
> the kernel did not panic
> ddb{0}> 
> the kernel di no paniddb{0}> 
> the erne i nic
> ddb{0}> 
> the kernel did not nic
> ddb{0}> 
> thernel id not nc
> ddb{0}> 
> the keel did notpanic
> ddb{0}> 
> theknel did not nic
> ddb{0}> 
> the kernel did not panic
> ddb{0}> 
> the kernel did not panic
> ddb{0}> 
> the kernel did not panc
> ddb0}> 
> the kernel did not panic
> ddb{0}> traccce
> No such command
> ddb{0}> 
> the kernel did not panic
> ddb{0}> tracce
> No such command
> ddb{0}> traace
> No such command
> ddb{0}> trace
> acpicpu_idle() at acpicpu_idle+0x1ea
> sched_idle(0) at sched_idle+0x245
> end trace frame: 0x0, count: -2
> ddb{0}> 
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> 
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> 
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> 
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> 
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> 
> acpicpu_idle() at acpicpu_idle+0x1ea
> end trace frame: 0x8000218fca60, count: 0
> ddb{0}> boot dump
> syncing disks..
> 
> 
> 
> 
> ddb{1}> boot dump
> syncing disks...panic: kernel diagnostic assertion "p->p_wchan == NULL" 
> failed: file "/usr/src/sys/kern/kern_sched.c", line 338
> Stopped at  db_enter+0x12:  popq%r11
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>   72309  19595 730x100010   0x800  syslogd
> db_enter() at db_enter+0x12
> panic() at panic+0x120
> __assert(811929f4,80002191fa00,800021750ff0,8000e960) 
> a
> t __assert+0x24
> sched_chooseproc() at sched_chooseproc+0x241
> mi_switch() at mi_switch+0x1b4
> sleep_finish(6d3fbc03daad5a02,80002191fb10) at sleep_finish+0x7f
> sleep_finish_all(270c6ff115c03531,80002191fb10) at sleep_finish_all+0x1f
> tsleep(64263b673ec8ed92,ff02417d4200,ff027f616830,65420) at 
> tsleep+0xcd
> 
> getblk(f6e14443bcd449df,ff027f6167d0,80002191fd00,0,ff027f3d3000) 
> a
> t getblk+0xf5
> bread(80145000,ff027f616a28,ff027f3d3000,0) at bread+0x1b
> ffs_update(292bb10918b461bf,ff027f616a28) at ffs_update+0xfc
> VOP_FSYNC(f6e14443bcb92266,80002191fe38,2be1d547d68afbf,8000e960) 
> a
> t VOP_FSYNC+0x52
> ffs_sync_vnode(5116a32c89f5a557,80002191fe38) at ffs_sync_vnode+0xd2
> vfs_mount_foreach_vnode(9582de35d54b8f61,2,8000e960) at 
> vfs_mount_forea
> ch_vnode+0x4e
> end trace frame: 0x80002191fea0, 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{1}> boot sync
> panic: kernel diagnostic assertion "__mp_lock_held(_lock, curcpu()) == 
> 0" failed: file "/usr/src/sys/kern/kern_lock.c", line 63
> Stopped at  db_enter+0x12:  popq%r11
> db_enter() at db_enter+0x12
> panic() at panic+0x120
> __assert(811929f4,80002191f530,0,ff02369aeae8) at 
> __assert+0x24
> 
> _kernel_lock(778d687e7309b96e,1) at _kernel_lock+0xea
> solock(537a4000962b3bf3) at solock+0x44
> route_input(6e54ffebe841494b,80002191f610,8012f000) at 
> route_input+
> 0xd1
> if_down(8012f000) at if_down+0x94
> if_downall() at if_downall+0x62
> boot(c) at boot+0x8d
> reboot(4800) at reboot+0x5a
> nvramattach(81d05260) at nvramattach
> db_boot_sync_cmd(819a1c9e,80002191f6c0,81d05260,1) at 
> db_bo
> ot_sync_cmd+0xe
> db_command(be4ef64b60647db8,0) at db_command+0x2b4
> db_command_loop() at db_command_loop+0x96
> end trace frame: 0x80002191f820, count: 0
> ddb{1}>
> 
> 
> 
> ddb{1}> dmesg  
> OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 

Strange kernel panic-like problem

[Kyle]

I recently upgraded a box running 6.2 to 6.4 via clean install. After a few 
days of running normally it started locking up, usually within a minute or so 
after booting up to the login prompt. ddb appears on the console.

I eventually thought to try booting bsd.sp, which has been running for about a 
day now without locking up.

Any clues to point me in the right direction would be much appreciated.

Here's some excerpts from the serial console (different sessions) and a dmesg:


ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
acpicpu_idle() at acpicpu_idle+0x1ea
sched_idle(0) at sched_idle+0x245
end trace frame: 0x0, count: -2



login: NMI ... going o debugger
ddb{0}䀿   movq$0x8,%rcxuaei[1;24r c
   db{}> 
ddb{0}> 
d{0}> 
ddb{0} 
ddb{0}> 
ddb{0}> 
ddb{�}> 
ddb{0> 
db{0}> show panic
the kernel did not panic
ddb{0}> 
the kernel did not panic
ddb{0}> 
the kernel did not panic
ddb{0}> 
the kernel did not panic
ddb{0}> 
the kernel di no paniddb{0}> 
the erne i nic
ddb{0}> 
the kernel did not nic
ddb{0}> 
thernel id not nc
ddb{0}> 
the keel did notpanic
ddb{0}> 
theknel did not nic
ddb{0}> 
the kernel did not panic
ddb{0}> 
the kernel did not panic
ddb{0}> 
the kernel did not panc
ddb0}> 
the kernel did not panic
ddb{0}> traccce
No such command
ddb{0}> 
the kernel did not panic
ddb{0}> tracce
No such command
ddb{0}> traace
No such command
ddb{0}> trace
acpicpu_idle() at acpicpu_idle+0x1ea
sched_idle(0) at sched_idle+0x245
end trace frame: 0x0, count: -2
ddb{0}> 
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> 
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> 
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> 
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> 
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> 
acpicpu_idle() at acpicpu_idle+0x1ea
end trace frame: 0x8000218fca60, count: 0
ddb{0}> boot dump
syncing disks..




ddb{1}> boot dump
syncing disks...panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: 
file "/usr/src/sys/kern/kern_sched.c", line 338
Stopped at  db_enter+0x12:  popq%r11
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
  72309  19595 730x100010   0x800  syslogd
db_enter() at db_enter+0x12
panic() at panic+0x120
__assert(811929f4,80002191fa00,800021750ff0,8000e960) a
t __assert+0x24
sched_chooseproc() at sched_chooseproc+0x241
mi_switch() at mi_switch+0x1b4
sleep_finish(6d3fbc03daad5a02,80002191fb10) at sleep_finish+0x7f
sleep_finish_all(270c6ff115c03531,80002191fb10) at sleep_finish_all+0x1f
tsleep(64263b673ec8ed92,ff02417d4200,ff027f616830,65420) at tsleep+0xcd

getblk(f6e14443bcd449df,ff027f6167d0,80002191fd00,0,ff027f3d3000) a
t getblk+0xf5
bread(80145000,ff027f616a28,ff027f3d3000,0) at bread+0x1b
ffs_update(292bb10918b461bf,ff027f616a28) at ffs_update+0xfc
VOP_FSYNC(f6e14443bcb92266,80002191fe38,2be1d547d68afbf,8000e960) a
t VOP_FSYNC+0x52
ffs_sync_vnode(5116a32c89f5a557,80002191fe38) at ffs_sync_vnode+0xd2
vfs_mount_foreach_vnode(9582de35d54b8f61,2,8000e960) at vfs_mount_forea
ch_vnode+0x4e
end trace frame: 0x80002191fea0, 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{1}> boot sync
panic: kernel diagnostic assertion "__mp_lock_held(_lock, curcpu()) == 0" 
failed: file "/usr/src/sys/kern/kern_lock.c", line 63
Stopped at  db_enter+0x12:  popq%r11
db_enter() at db_enter+0x12
panic() at panic+0x120
__assert(811929f4,80002191f530,0,ff02369aeae8) at __assert+0x24

_kernel_lock(778d687e7309b96e,1) at _kernel_lock+0xea
solock(537a4000962b3bf3) at solock+0x44
route_input(6e54ffebe841494b,80002191f610,8012f000) at route_input+
0xd1
if_down(8012f000) at if_down+0x94
if_downall() at if_downall+0x62
boot(c) at boot+0x8d
reboot(4800) at reboot+0x5a
nvramattach(81d05260) at nvramattach
db_boot_sync_cmd(819a1c9e,80002191f6c0,81d05260,1) at db_bo
ot_sync_cmd+0xe
db_command(be4ef64b60647db8,0) at db_command+0x2b4
db_command_loop() at db_command_loop+0x96
end trace frame: 0x80002191f820, count: 0
ddb{1}>



ddb{1}> dmesg  
OpenBSD 6.4 (GENERIC.MP) #6: Sat Jan 26 20:37:44 CET 2019
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.
MP
real mem = 8544854016 (8149MB)
avail mem = 8276611072 (7893MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (50 entries)
bios0: vendor American Megatrends Inc. version "1.1a" date 08/27/2015
bios0: Supermicro A1SAi
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT 

Re: Problem upgrading to today's snapshot on VirtualBox 6 installation (kernel panic)

[Andreas Kusalananda Kähäri]

On Mon, Jan 14, 2019 at 12:16:29PM +0100, Andreas Kusalananda Kähäri wrote:
> On Mon, Jan 14, 2019 at 10:25:03AM +0100, Andreas Kusalananda Kähäri wrote:
> > 
> > Hi,
> > 
> > Today's snapshot, timestamped "14/01/2019, 08:18:00" on the
> > ftp.eu.openbsd.org mirror, fails to do an upgrade on my VirtualBox 6
> > amd64 installation (which I'm running on top of macOS Mojave).

The snapshot dated "14/01/2019, 21:38:00" on ftp.eu.openbsd.org no
longer exhibit this issue.

Thanks.




> > 
> > The installation gets to the stage where I'm supposed to get to select
> > the bits to install, but before it gets there, the machine resets.
> > 
> > The VirtualBox log says "ACPI: Reset initiated by ACPI" when this
> > happens when upgrading using install64.iso, but this is missing when
> > I tried using cd64.iso so I'm not sure it's related (same behaviour
> > though, the machine resets).
> > 
> > I saw a backed out libc commit by Otto with the comment "Unbreak
> > tree. Last minute changes are evil", but I'm not sure this is related
> > either, or whether the backed out commit made it into the snapshot
> > (probably not).
> 
> The new snapshot, "14/01/2019, 10:38:00", also does not work.  Same
> "ACPI: Reset initiated by ACPI" in the VirtualBox log. This time I
> managed to capture a kernel panic by hooking up a serial console:
> 
> Let's upgrade the sets!
> Location of sets? (cd0 disk http or 'done') [http] cd0
> cd0
> 
> Pathname to the sets? (or 'done') [6.4/amd64]
> Select sets by entering a set name, a file name pattern or 'all'. De-select
> sets by prepending a '-', e.g.: '-game*'. Selected sets are labelled '[X]'.
> [X] bsd   [X] base64.tgz[X] game64.tgz[X] xfont64.tgz
> [X] bsd.mp[X] comp64.tgz[X] xbase64.tgz   [X] xserv64.tgz
> [X] bsd.rd[X] man64.tgz [X] xshare64.tgz
> uvm_fault(0xff011eb92638, 0x0, 0, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip 810f94c9 cs 8 rflags 10246 cr2  0 cpl 0 rsp 
> 8000220df600
> gsbase 0x81877ff0  kgsbase 0x0
> panic: trap type 6, code=0, pc=810f94c9
> syncing disks... done
> 
> dump to dev 17,1 not possible
> rebooting...
> 
> 
> > 
> > 
> > dmesg of un-upgraded system included:
> > 
> > 
> > OpenBSD 6.4-current (GENERIC.MP) #611: Sun Jan 13 10:18:36 MST 2019
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 4278124544 (4079MB)
> > avail mem = 4138897408 (3947MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
> > bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
> > bios0: innotek GmbH VirtualBox
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S5
> > acpi0: tables DSDT FACP APIC SSDT
> > acpi0: wakeup devices
> > acpitimer0 at acpi0: 3579545 Hz, 32 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3193.13 MHz, 06-3c-03
> > 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,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,AVX2,INVPCID,MELTDOWN
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: smt 0, core 0, package 0
> > mtrr: CPU supports MTRRs but not enabled by BIOS
> > cpu0: apic clock running at 1000MHz
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.88 MHz, 06-3c-03
> > 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,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,AVX2,INVPCID,MELTDOWN
> > cpu1: 256KB 64b/line 8-way L2 cache
> > cpu1: smt 0, core 1, package 0
> > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpicpu0 at acpi0: C1(@1 halt!)
> > acpicpu1 at acpi0: C1(@1 halt!)
> > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> > acpiac0 at acpi0: AC unit online
> > acpivideo0 at acpi0: GFX0
> > pci0 at mainbus0 bus 0
> > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> > vga1 at pci0 dev 2 funct

Re: Problem upgrading to today's snapshot on VirtualBox 6 installation (kernel panic)

[Andreas Kusalananda Kähäri]

On Mon, Jan 14, 2019 at 10:25:03AM +0100, Andreas Kusalananda Kähäri wrote:
> 
> Hi,
> 
> Today's snapshot, timestamped "14/01/2019, 08:18:00" on the
> ftp.eu.openbsd.org mirror, fails to do an upgrade on my VirtualBox 6
> amd64 installation (which I'm running on top of macOS Mojave).
> 
> The installation gets to the stage where I'm supposed to get to select
> the bits to install, but before it gets there, the machine resets.
> 
> The VirtualBox log says "ACPI: Reset initiated by ACPI" when this
> happens when upgrading using install64.iso, but this is missing when
> I tried using cd64.iso so I'm not sure it's related (same behaviour
> though, the machine resets).
> 
> I saw a backed out libc commit by Otto with the comment "Unbreak
> tree. Last minute changes are evil", but I'm not sure this is related
> either, or whether the backed out commit made it into the snapshot
> (probably not).

The new snapshot, "14/01/2019, 10:38:00", also does not work.  Same
"ACPI: Reset initiated by ACPI" in the VirtualBox log. This time I
managed to capture a kernel panic by hooking up a serial console:

Let's upgrade the sets!
Location of sets? (cd0 disk http or 'done') [http] cd0
cd0

Pathname to the sets? (or 'done') [6.4/amd64]
Select sets by entering a set name, a file name pattern or 'all'. De-select
sets by prepending a '-', e.g.: '-game*'. Selected sets are labelled '[X]'.
[X] bsd   [X] base64.tgz[X] game64.tgz[X] xfont64.tgz
[X] bsd.mp[X] comp64.tgz[X] xbase64.tgz   [X] xserv64.tgz
[X] bsd.rd[X] man64.tgz [X] xshare64.tgz
uvm_fault(0xff011eb92638, 0x0, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 810f94c9 cs 8 rflags 10246 cr2  0 cpl 0 rsp 
8000220df600
gsbase 0x81877ff0  kgsbase 0x0
panic: trap type 6, code=0, pc=810f94c9
syncing disks... done

dump to dev 17,1 not possible
rebooting...


> 
> 
> dmesg of un-upgraded system included:
> 
> 
> OpenBSD 6.4-current (GENERIC.MP) #611: Sun Jan 13 10:18:36 MST 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4278124544 (4079MB)
> avail mem = 4138897408 (3947MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
> bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
> bios0: innotek GmbH VirtualBox
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP APIC SSDT
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3193.13 MHz, 06-3c-03
> 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,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,AVX2,INVPCID,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: CPU supports MTRRs but not enabled by BIOS
> cpu0: apic clock running at 1000MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.88 MHz, 06-3c-03
> 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,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,ITSC,FSGSBASE,AVX2,INVPCID,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpiac0 at acpi0: AC unit online
> acpivideo0 at acpi0: GFX0
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio0: address 08:00:27:01:15:d1
> virtio0: apic 2 int 19
> "InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not 
> configured
> piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 2 int 23
> iic0 at piixpm0
> virtio1 at pci0 dev 8 function 0 "Qumranet Virtio Network" rev 0x00
> vio1

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Mike Larkin]

On Mon, Oct 22, 2018 at 08:59:46PM +0300, snikolov wrote:
> On Mon, 2018-10-22 at 10:27 -0700, Mike Larkin wrote:
> > On Mon, Oct 22, 2018 at 10:13:14AM -0700, Mike Larkin wrote:
> > > On Mon, Oct 22, 2018 at 08:01:13PM +0300, snikolov wrote:
> > > > > This appears to be related to the LFENCE serializing MSR change
> > > > > that
> > > > > went in
> > > > > during the last round of side channel analysis fixes:
> > > > > 
> > > > > 811c3037:   b9 29 10 01
> > > > > c0  mov$0xc0011029,%ecx
> > > > > 811c303c:   0f 32   rdmsr
> > > > > 
> > > > > According to the commit, "This MSR is available on all AMD
> > > > > families
> > > > > > = 10h...",
> > > > > 
> > > > > and since yours is family 15h, it should work. Maybe that
> > > > > assumption
> > > > > was wrong?
> > > > > 
> > > > > -ml
> > > > > 
> > > > 
> > > > The Host's CPU is FX-8350 ,so you assumed right. Yet, I am new to
> > > > openBSD so I have no clue what approach to be taken.
> > > > 
> > > > Strahil
> > > 
> > > Maybe a BIOS update is available? The date on yours is 2014. Maybe
> > > they
> > > added that MSR after?
> > > 
> > 
> > As brynet@ pointed out in a later reply, BIOS update probably won't
> > help.
> > 
> > -ml
> > 
> 
> BIOS update is unavailable, yet the microcode patch_level is
> '0x06000852'. The kernel is: 3.10.0-862.3.3.el7.x86_64
> 
> Any kernel parameters to disable the mitigations and still leave the
> CPU at Opteron_G5 ?
> 
> Strahil
> 

Not from the OpenBSD side.

-ml

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[snikolov]

On Mon, 2018-10-22 at 10:27 -0700, Mike Larkin wrote:
> On Mon, Oct 22, 2018 at 10:13:14AM -0700, Mike Larkin wrote:
> > On Mon, Oct 22, 2018 at 08:01:13PM +0300, snikolov wrote:
> > > > This appears to be related to the LFENCE serializing MSR change
> > > > that
> > > > went in
> > > > during the last round of side channel analysis fixes:
> > > > 
> > > > 811c3037:   b9 29 10 01
> > > > c0  mov$0xc0011029,%ecx
> > > > 811c303c:   0f 32   rdmsr
> > > > 
> > > > According to the commit, "This MSR is available on all AMD
> > > > families
> > > > > = 10h...",
> > > > 
> > > > and since yours is family 15h, it should work. Maybe that
> > > > assumption
> > > > was wrong?
> > > > 
> > > > -ml
> > > > 
> > > 
> > > The Host's CPU is FX-8350 ,so you assumed right. Yet, I am new to
> > > openBSD so I have no clue what approach to be taken.
> > > 
> > > Strahil
> > 
> > Maybe a BIOS update is available? The date on yours is 2014. Maybe
> > they
> > added that MSR after?
> > 
> 
> As brynet@ pointed out in a later reply, BIOS update probably won't
> help.
> 
> -ml
> 

BIOS update is unavailable, yet the microcode patch_level is
'0x06000852'. The kernel is: 3.10.0-862.3.3.el7.x86_64

Any kernel parameters to disable the mitigations and still leave the
CPU at Opteron_G5 ?

Strahil

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Mike Larkin]

On Mon, Oct 22, 2018 at 10:13:14AM -0700, Mike Larkin wrote:
> On Mon, Oct 22, 2018 at 08:01:13PM +0300, snikolov wrote:
> > > This appears to be related to the LFENCE serializing MSR change that
> > > went in
> > > during the last round of side channel analysis fixes:
> > > 
> > > 811c3037:   b9 29 10 01
> > > c0  mov$0xc0011029,%ecx
> > > 811c303c:   0f 32   rdmsr
> > > 
> > > According to the commit, "This MSR is available on all AMD families
> > > >= 10h...",
> > > and since yours is family 15h, it should work. Maybe that assumption
> > > was wrong?
> > > 
> > > -ml
> > > 
> > The Host's CPU is FX-8350 ,so you assumed right. Yet, I am new to
> > openBSD so I have no clue what approach to be taken.
> > 
> > Strahil
> 
> Maybe a BIOS update is available? The date on yours is 2014. Maybe they
> added that MSR after?
> 

As brynet@ pointed out in a later reply, BIOS update probably won't help.

-ml

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Mike Larkin]

On Mon, Oct 22, 2018 at 08:01:13PM +0300, snikolov wrote:
> > This appears to be related to the LFENCE serializing MSR change that
> > went in
> > during the last round of side channel analysis fixes:
> > 
> > 811c3037:   b9 29 10 01
> > c0  mov$0xc0011029,%ecx
> > 811c303c:   0f 32   rdmsr
> > 
> > According to the commit, "This MSR is available on all AMD families
> > >= 10h...",
> > and since yours is family 15h, it should work. Maybe that assumption
> > was wrong?
> > 
> > -ml
> > 
> The Host's CPU is FX-8350 ,so you assumed right. Yet, I am new to
> openBSD so I have no clue what approach to be taken.
> 
> Strahil

Maybe a BIOS update is available? The date on yours is 2014. Maybe they
added that MSR after?

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Bryan Steele]

On Mon, Oct 22, 2018 at 09:49:54AM -0700, Mike Larkin wrote:
> On Mon, Oct 22, 2018 at 07:09:21AM +0300, snikolov wrote:
> > Dear All,
> > 
> > I have managed to configure and get the output of the serial console on
> > KVM and here is the output (with different CPU type only the name of
> > the CPU changes) :
> > ~~
> > >> OpenBSD/amd64 CDBOOT 3.40
> > boot> 
> > cannot open cd0a:/etc/random.seed: No such file or directory
> > booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016
> > [372715+111+441072+293323]=0xa208a0
> > entry point at 0x1000158
> > Copyright (c) 1982, 1986, 1989, 1991, 1993
> > The Regents of the University of California.  All rights
> > reserved.
> > Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.Open
> > BSD.org
> > 
> > OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C
> > D
> > real mem = 4278030336 (4079MB)
> > avail mem = 4144590848 (3952MB)
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6110 (11 entries)
> > bios0: vendor SeaBIOS version "1.11.0-2.el7" date 04/01/2014
> > bios0: Red Hat KVM
> > acpi0 at bios0: rev 0
> > acpi0: tables DSDT FACP APIC
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Opteron 63xx class CPU, 3992.09 MHz, 15-02-00
> > cpu0:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
> > ,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2A
> > PIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,PAGE1GB,LONG,LAHF,ABM,SSE4A,MASSE,
> > 3DNOWP,XOP,FMA4,TBM
> > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache
> > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> > fatal protection fault in supervisor mode
> > trap type 4 code 0 rip 811c303c cs 8 rflags 10202 cr2  0 cpl e
> > rsp 81a06a20
> > gsbase 0x81872ff0  kgsbase 0x0
> > panic: trap type 4, code=0, pc=811c303c
> > 
> > The operating system has halted.
> > Please press any key to reboot.
> > ~~
> > 
> > Should I report this as a bug ?
> > 
> > Best Regards,
> > Strahil Nikolov
> > 
> > 
> > On Sun, 2018-10-21 at 18:07 +0300, snikolov wrote:
> > > Hello All,
> > > 
> > > During install of install64.iso I experience a kernel panic during
> > > boot of the CD (pc=811c303c).
> > > install64.iso sha256sum is
> > > 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2
> > > which
> > > matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256
> > > 
> > > I have tested with various CPUs on my RHEL 7.5 and it seems that
> > > Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the
> > > panic,while
> > > Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I
> > > got the installer prompt.
> > > 
> > > Does anyone observes the same behaviour or it is only me ?
> > > 
> > > Best Regards,
> > > Strahil Nikolov
> > 
> 
> This appears to be related to the LFENCE serializing MSR change that went in
> during the last round of side channel analysis fixes:
> 
> 811c3037:   b9 29 10 01 c0  mov$0xc0011029,%ecx
> 811c303c:   0f 32   rdmsr
> 
> According to the commit, "This MSR is available on all AMD families >= 
> 10h...",
> and since yours is family 15h, it should work. Maybe that assumption was 
> wrong?
> 
> -ml

This appears to be another case of an outdated host kernel / KVM
combination. If you tried to boot OpenBSD on the bare hardware,
it wouldn't panic.

We're following AMD's recommendation here, as far as can tell.

https://marc.info/?l=openbsd-misc=153315801921789=2

-Bryan.

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[snikolov]

> This appears to be related to the LFENCE serializing MSR change that
> went in
> during the last round of side channel analysis fixes:
> 
> 811c3037:   b9 29 10 01
> c0  mov$0xc0011029,%ecx
> 811c303c:   0f 32   rdmsr
> 
> According to the commit, "This MSR is available on all AMD families
> >= 10h...",
> and since yours is family 15h, it should work. Maybe that assumption
> was wrong?
> 
> -ml
> 
The Host's CPU is FX-8350 ,so you assumed right. Yet, I am new to
openBSD so I have no clue what approach to be taken.

Strahil

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Mike Larkin]

On Mon, Oct 22, 2018 at 07:09:21AM +0300, snikolov wrote:
> Dear All,
> 
> I have managed to configure and get the output of the serial console on
> KVM and here is the output (with different CPU type only the name of
> the CPU changes) :
> ~~
> >> OpenBSD/amd64 CDBOOT 3.40
> boot> 
> cannot open cd0a:/etc/random.seed: No such file or directory
> booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016
> [372715+111+441072+293323]=0xa208a0
> entry point at 0x1000158
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights
> reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.Open
> BSD.org
> 
> OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C
> D
> real mem = 4278030336 (4079MB)
> avail mem = 4144590848 (3952MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6110 (11 entries)
> bios0: vendor SeaBIOS version "1.11.0-2.el7" date 04/01/2014
> bios0: Red Hat KVM
> acpi0 at bios0: rev 0
> acpi0: tables DSDT FACP APIC
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Opteron 63xx class CPU, 3992.09 MHz, 15-02-00
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
> ,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2A
> PIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,PAGE1GB,LONG,LAHF,ABM,SSE4A,MASSE,
> 3DNOWP,XOP,FMA4,TBM
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> fatal protection fault in supervisor mode
> trap type 4 code 0 rip 811c303c cs 8 rflags 10202 cr2  0 cpl e
> rsp 81a06a20
> gsbase 0x81872ff0  kgsbase 0x0
> panic: trap type 4, code=0, pc=811c303c
> 
> The operating system has halted.
> Please press any key to reboot.
> ~~
> 
> Should I report this as a bug ?
> 
> Best Regards,
> Strahil Nikolov
> 
> 
> On Sun, 2018-10-21 at 18:07 +0300, snikolov wrote:
> > Hello All,
> > 
> > During install of install64.iso I experience a kernel panic during
> > boot of the CD (pc=811c303c).
> > install64.iso sha256sum is
> > 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2
> > which
> > matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256
> > 
> > I have tested with various CPUs on my RHEL 7.5 and it seems that
> > Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the
> > panic,while
> > Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I
> > got the installer prompt.
> > 
> > Does anyone observes the same behaviour or it is only me ?
> > 
> > Best Regards,
> > Strahil Nikolov
> 

This appears to be related to the LFENCE serializing MSR change that went in
during the last round of side channel analysis fixes:

811c3037:   b9 29 10 01 c0  mov$0xc0011029,%ecx
811c303c:   0f 32   rdmsr

According to the commit, "This MSR is available on all AMD families >= 10h...",
and since yours is family 15h, it should work. Maybe that assumption was wrong?

-ml

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[snikolov]

Dear All,

I have managed to configure and get the output of the serial console on
KVM and here is the output (with different CPU type only the name of
the CPU changes) :
~~
>> OpenBSD/amd64 CDBOOT 3.40
boot> 
cannot open cd0a:/etc/random.seed: No such file or directory
booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016
[372715+111+441072+293323]=0xa208a0
entry point at 0x1000158
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights
reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.Open
BSD.org

OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C
D
real mem = 4278030336 (4079MB)
avail mem = 4144590848 (3952MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6110 (11 entries)
bios0: vendor SeaBIOS version "1.11.0-2.el7" date 04/01/2014
bios0: Red Hat KVM
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron 63xx class CPU, 3992.09 MHz, 15-02-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2A
PIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,PAGE1GB,LONG,LAHF,ABM,SSE4A,MASSE,
3DNOWP,XOP,FMA4,TBM
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
fatal protection fault in supervisor mode
trap type 4 code 0 rip 811c303c cs 8 rflags 10202 cr2  0 cpl e
rsp 81a06a20
gsbase 0x81872ff0  kgsbase 0x0
panic: trap type 4, code=0, pc=811c303c

The operating system has halted.
Please press any key to reboot.
~~

Should I report this as a bug ?

Best Regards,
Strahil Nikolov


On Sun, 2018-10-21 at 18:07 +0300, snikolov wrote:
> Hello All,
> 
> During install of install64.iso I experience a kernel panic during
> boot of the CD (pc=811c303c).
> install64.iso sha256sum is
> 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2
> which
> matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256
> 
> I have tested with various CPUs on my RHEL 7.5 and it seems that
> Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the
> panic,while
> Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I
> got the installer prompt.
> 
> Does anyone observes the same behaviour or it is only me ?
> 
> Best Regards,
> Strahil Nikolov

amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[snikolov]

Hello All,

During install of install64.iso I experience a kernel panic during
boot of the CD (pc=811c303c).
install64.iso sha256sum is
81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2 which
matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256

I have tested with various CPUs on my RHEL 7.5 and it seems that
Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the panic,while
Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I
got the installer prompt.

Does anyone observes the same behaviour or it is only me ?

Best Regards,
Strahil Nikolov

Re: kernel panic while reproducing video with mpv

[Walter Alejandro Iglesias]

Hi Visa,

On Sun, Jun 24, 2018 at 05:54:15PM +, Visa Hankala wrote:
> On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote:
> > panic: mtx 0x81c86470: locking against myself
> > Stopped at  db_enter+0x12:  popq%r11
> > TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> >  104021  96401   1000 0x3  0x4002  mpv
> > *402610  50624   10000x32  00K Xorg
> >   
> > db_enter() at db_enter+0x12
> > panic() at panic+0x138
> > __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
> > _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a
> > printf(c9ef1007dec621e0) at printf+0x70
> > witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00)
> >  at 
> > witness_checkorder+0x943
> > ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70
> > selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
> > ptsstart(8ce5939828d5e23) at ptsstart+0x79
> > tputchar(174549bf676e909c,80afa400) at tputchar+0x85
> > kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91
> > kprintf() at kprintf+0xe8
> > printf(c9ef1007dec621e0) at printf+0x85
> > witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff
> > ff81c8a688) at witness_checkorder+0x943
> > end trace frame: 0x80003302e978, count: 0
> 
> If the panic happens again, please run the following commands in ddb(4)
> and post the output:
> 
> show locks
> show all locks

The true is it happend twice.  On the first one fsck(8) couldn't recover
my root file system.  After rebooting I couldn't even log in (as user or
root) and I had to reinstall.  That's way I'm not confident about
"voluntary" reproducing the bug. :-)  But if it happens again take for
sure I'll send you the output of those commands (and per cpu traces).

> 
> It is not clear from the stack trace why the system begins to report
> a lock order problem in the first place (the first witness_checkorder
> and the printf at the end of the stack trace).
> 
> The panic itself is related to the problem of using other kernel
> subsystems from WITNESS. I will try to make a fix that should prevent
> the panic in most cases.


Thanks!

Walter

Re: kernel panic while reproducing video with mpv

[Visa Hankala]

On Sun, Jun 24, 2018 at 12:37:45PM +0200, Walter Alejandro Iglesias wrote:
> panic: mtx 0x81c86470: locking against myself
> Stopped at  db_enter+0x12:  popq%r11
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>  104021  96401   1000 0x3  0x4002  mpv
> *402610  50624   10000x32  00K Xorg
>   
> db_enter() at db_enter+0x12
> panic() at panic+0x138
> __mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
> _mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a
> printf(c9ef1007dec621e0) at printf+0x70
> witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00) 
> at 
> witness_checkorder+0x943
> ___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70
> selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
> ptsstart(8ce5939828d5e23) at ptsstart+0x79
> tputchar(174549bf676e909c,80afa400) at tputchar+0x85
> kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91
> kprintf() at kprintf+0xe8
> printf(c9ef1007dec621e0) at printf+0x85
> witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff
> ff81c8a688) at witness_checkorder+0x943
> end trace frame: 0x80003302e978, count: 0

If the panic happens again, please run the following commands in ddb(4)
and post the output:

show locks
show all locks

It is not clear from the stack trace why the system begins to report
a lock order problem in the first place (the first witness_checkorder
and the printf at the end of the stack trace).

The panic itself is related to the problem of using other kernel
subsystems from WITNESS. I will try to make a fix that should prevent
the panic in most cases.

kernel panic while reproducing video with mpv

[Walter Alejandro Iglesias]

Hello,

I had a kernel panic while reproducing a video with mpv.

It's my first kernel panic with OpenBSD, so I didn't know how to use
ddb(4).  Since I'm running my http and smtp server in this machine I
cannot entertain myself too much reproducing the panic to get more info.
That's why I don't include the per cpu trace and other additonal info as
explained in ddb.html, sorry!  But, if you need it let me knonw and I'll
try my best.


Message automatically dumped:
===
panic: mtx 0x81c86470: locking against myself
Stopped at  db_enter+0x12:  popq%r11
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND  
 
 104021  96401   1000 0x3  0x4002  mpv  
  
*402610  50624   10000x32  00K Xorg 
  
db_enter() at db_enter+0x12
panic() at panic+0x138
__mtx_enter_try(53b9235709d40154) at __mtx_enter_try+0xb5
_mtx_enter(81cf3e60,81a5d6a2,0) at _mtx_enter+0x5a
printf(c9ef1007dec621e0) at printf+0x70
witness_checkorder(2e4447d1b3cbb9af,81c2ac7c,32a,0,81da6d00) at 
witness_checkorder+0x943
___mp_lock(8000330cd760,d,7) at ___mp_lock+0x70
selwakeup(e80faaebded7c1a2) at selwakeup+0x9c
ptsstart(8ce5939828d5e23) at ptsstart+0x79
tputchar(174549bf676e909c,80afa400) at tputchar+0x85
kputchar(75d50501b895e9e4,0,81a5d6a2) at kputchar+0x91
kprintf() at kprintf+0xe8
printf(c9ef1007dec621e0) at printf+0x85
witness_checkorder(2e4447d1b3cba2fe,81af9df1,298,81c8a678,ff
ff81c8a688) at witness_checkorder+0x943
end trace frame: 0x80003302e978, count: 0


dmesg:
===
OpenBSD 6.3-current (GENERIC.MP) #48: Fri Jun 22 14:11:27 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6210174976 (5922MB)
avail mem = 5960577024 (5684MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6IET85WW (1.45 )" date 02/14/2013
bios0: LENOVO 2537EY8
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT S
SDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4
(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.56 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,
PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-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 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,
PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,
PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,
PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 13 (EXP5)
acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), C1(1000@3
 mwait.1), PS

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Jan Vlach]

> Hi,
> 
> could you please try this diff from kettenis@
> https://marc.info/?l=openbsd-tech=152650279308779=2
> 

Hi Hrvoje, misc@,

I'm sorry, but I don't access to the hardware (Dell PowerEdge R440) anymore.
I've returned it to the supplier already as this was leased only for
testing.

Sorry,
Jan

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Hrvoje Popovski]

On 2.5.2018. 11:28, Jan Vlach wrote:
> R440 WAS( Re: Dell PowerEdge R430/R440 support)
> Reply-To: 
> In-Reply-To: <20180425150215.gh20...@diehard.n-r-g.com>
> 
> Hello misc@
> 
> 
> the Dell PowerEdge R440 server arrived for testing and it panics on boot
> to installed system. Installer works fine, it's the reboot into
> installed system that fails. Both 6.3-release and 6.3-current behave the
> same. (OpenBSD 6.3-current (RAMDISK_CD) #12: Wed Apr 25 22:56:41 MDT
> 2018; dmesg below)
> 
> I've turned PERC H330 into HBA mode and setup raid1 softraid from 3
> disks.
> 
> last screen on monitor with panic (rewritten by hand, sorry for possible 
> typos, photo at
> https://synchronicity.cz/bsd/ )
> 
> ### LAST PANIC SCREEN
> acpiprt81 at acpi0: bus -1 (SR3A)
> acpiprt82 at acpi0: bus -1 (SR3B)
> acpiprt83 at acpi0: bus -1 (SR3C)
> acpiprt84 at acpi0: bus -1 (SR3D)
> acpiprt85 at acpi0: bus -1 (MCP6)
> acpiprt86 at acpi0: bus -1 (MCP7)
> acpicpu0 at acpi0LoadTable
> 0140 Called: \_SB_.SCK0.CP00.ISTT
> 0140 Called: \_SB_.SCK0.CP00.ISTT
> 034d Called: \_SB_.SCK0.CP00._OSC
>   arg0: 0x80620488 cnt:05 stk: 00 buffer: 10 {16, a6, 77, 40,
> 0c, 29, be, 47, 9e, bd, d8, 70, 58, 71, 39, 53}
>   arg1: 0x80627988 cnt:01 stk:00 integer: 1 arg2: 0x80629388 
> cnt:01 stk:00 integer: 2
>   arg3: 0x8061d188 cnt:04 stk:00 buffer: 0c {00, 00, 00, 00, 3b,
> 03, 00, 00, ff, ff, ff, ff}
> 034d Called: \_SB_.SCK0.CP00._OSC
>   arg0: 0x80620488 cnt:05 stk: 00 buffer: 10 {16, a6, 77, 40,
> 0c, 29, be, 47, 9e, bd, d8, 70, 58, 71, 39, 53}
>   arg1: 0x80627988 cnt:01 stk:00 integer: 1
>   arg2: 0x80629388 cnt:01 stk:00 integer: 2
>   arg3: 0x8061d188 cnt:04 stk:00 buffer: 0c {00, 00, 00, 00, 3b,
> 03, 00, 00, ff, ff, ff, ff}
> panic: aml_die aml_parse:4194


Hi,

could you please try this diff from kettenis@
https://marc.info/?l=openbsd-tech=152650279308779=2

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Mike Larkin]

On Thu, May 03, 2018 at 02:02:48PM +0200, Jan Vlach wrote:
> > kettenis@ may know more, I think he knows about this issue already. It's 
> > just
> > a missing piece of the standard we didn't implement yet. An AML dump may
> > be useful, yes.
> > 
> > -ml
> > 
> 
> Hello Mike,
> 
> just have installed FreeBSD11.1 on the PowerEdge R440 to get acpidump & debug
> info. I've followed
> https://docs.freebsd.org/doc/5.5-RELEASE/usr/share/doc/handbook/acpi-debug.html.
> 
> The files are available at: https://synchronicity.cz/bsd/ 
> Full archive at: https://synchronicity.cz/bsd/R440-FreeBSD.tar.gz
> 
> ### FILES
> FreeBSD11.1.aml # iasl -f FreeBSD11.1.asl 
> FreeBSD11.1.asl # acpidump -t -d > FreeBSD11.1.aml
> FreeBSD11.1.dsl # iasl -d  FreeBSD11.1.asl
> devinfo-rv.txt # devinfo -rv 
> devinfo-v.txt # devinfo -v 
> dmesg-FreeBSD11.1.txt # dmesg
> hw.acpi.txt # sysctl hw.acpi
> iasl-FreeBSD11.1.asl.txt # iasl console output
> iasl-f.log # iasl -f log
> pciconf-lv.txt # pciconf -lv 
> pciconv-l.txt # pciconv -l
> sysctl-a.txt # syscl -a
> usbconfig.txt # usbconfig
> 
> Is anything else needed/necessary? Is the `iasl -f` command what you meant by 
> getting an
> AML dump?
> 
> Thank you, 
> Jan
> 

What you posted to the URL above should probably be enough to get started, for
whomever decides to take on the challenge. At least for the time being, that's
not me. And not having access to the hardware makes it even less interesting :)

I grabbed the .tar.gz from above, in case the link dies, in case anyone later
needs the files.

-ml

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Jan Vlach]

> kettenis@ may know more, I think he knows about this issue already. It's just
> a missing piece of the standard we didn't implement yet. An AML dump may
> be useful, yes.
> 
> -ml
> 

Hello Mike,

just have installed FreeBSD11.1 on the PowerEdge R440 to get acpidump & debug
info. I've followed
https://docs.freebsd.org/doc/5.5-RELEASE/usr/share/doc/handbook/acpi-debug.html.

The files are available at: https://synchronicity.cz/bsd/ 
Full archive at: https://synchronicity.cz/bsd/R440-FreeBSD.tar.gz

### FILES
FreeBSD11.1.aml # iasl -f FreeBSD11.1.asl 
FreeBSD11.1.asl # acpidump -t -d > FreeBSD11.1.aml
FreeBSD11.1.dsl # iasl -d  FreeBSD11.1.asl
devinfo-rv.txt # devinfo -rv 
devinfo-v.txt # devinfo -v 
dmesg-FreeBSD11.1.txt # dmesg
hw.acpi.txt # sysctl hw.acpi
iasl-FreeBSD11.1.asl.txt # iasl console output
iasl-f.log # iasl -f log
pciconf-lv.txt # pciconf -lv 
pciconv-l.txt # pciconv -l
sysctl-a.txt # syscl -a
usbconfig.txt # usbconfig

Is anything else needed/necessary? Is the `iasl -f` command what you meant by 
getting an
AML dump?

Thank you, 
Jan

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Jan Vlach]

> Last time I checked, we don't support LoadTable.
> 
> -ml
> 

Thank you Mike for your reply. I have no clue about ACPI. Is this a new
way how vendors extend ACPI? Is there generally a way to switch it to
some "legacy" mode or is this endgame? 
Is there some info I could get from the system before I send it back
that could later down the road when someone is interested? Would getting
an acpidump from Linux and/or FreeBSD help at this point? 

Thank you again,
Jan

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Hrvoje Popovski]

On 2.5.2018. 19:06, Mike Larkin wrote:
> On Wed, May 02, 2018 at 06:51:51PM +0200, Jan Vlach wrote:
>>> Last time I checked, we don't support LoadTable.
>>>
>>> -ml
>>>
>>
>> Thank you Mike for your reply. I have no clue about ACPI. Is this a new
>> way how vendors extend ACPI? Is there generally a way to switch it to
>> some "legacy" mode or is this endgame? 
>> Is there some info I could get from the system before I send it back
>> that could later down the road when someone is interested? Would getting
>> an acpidump from Linux and/or FreeBSD help at this point? 
>>
>> Thank you again,
>> Jan
> 
> kettenis@ may know more, I think he knows about this issue already. It's just
> a missing piece of the standard we didn't implement yet. An AML dump may
> be useful, yes.
> 
> -ml
> 

Hi,

it seems that this is the same problem as on r640/r740. Please see

http://openbsd-archive.7691.n7.nabble.com/acpi-panic-on-dell-r640-and-r740xd-td339288.html

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Mike Larkin]

On Wed, May 02, 2018 at 06:51:51PM +0200, Jan Vlach wrote:
> > Last time I checked, we don't support LoadTable.
> > 
> > -ml
> > 
> 
> Thank you Mike for your reply. I have no clue about ACPI. Is this a new
> way how vendors extend ACPI? Is there generally a way to switch it to
> some "legacy" mode or is this endgame? 
> Is there some info I could get from the system before I send it back
> that could later down the road when someone is interested? Would getting
> an acpidump from Linux and/or FreeBSD help at this point? 
> 
> Thank you again,
> Jan

kettenis@ may know more, I think he knows about this issue already. It's just
a missing piece of the standard we didn't implement yet. An AML dump may
be useful, yes.

-ml

Re: 6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Mike Larkin]

On Wed, May 02, 2018 at 11:28:47AM +0200, Jan Vlach wrote:
> R440 WAS( Re: Dell PowerEdge R430/R440 support)
> Reply-To: 
> In-Reply-To: <20180425150215.gh20...@diehard.n-r-g.com>
> 
> Hello misc@
> 
> 
> the Dell PowerEdge R440 server arrived for testing and it panics on boot
> to installed system. Installer works fine, it's the reboot into
> installed system that fails. Both 6.3-release and 6.3-current behave the
> same. (OpenBSD 6.3-current (RAMDISK_CD) #12: Wed Apr 25 22:56:41 MDT
> 2018; dmesg below)
> 
> I've turned PERC H330 into HBA mode and setup raid1 softraid from 3
> disks.
> 
> last screen on monitor with panic (rewritten by hand, sorry for possible 
> typos, photo at
> https://synchronicity.cz/bsd/ )
> 

Last time I checked, we don't support LoadTable.

-ml

> ### LAST PANIC SCREEN
> acpiprt81 at acpi0: bus -1 (SR3A)
> acpiprt82 at acpi0: bus -1 (SR3B)
> acpiprt83 at acpi0: bus -1 (SR3C)
> acpiprt84 at acpi0: bus -1 (SR3D)
> acpiprt85 at acpi0: bus -1 (MCP6)
> acpiprt86 at acpi0: bus -1 (MCP7)
> acpicpu0 at acpi0LoadTable
> 0140 Called: \_SB_.SCK0.CP00.ISTT
> 0140 Called: \_SB_.SCK0.CP00.ISTT
> 034d Called: \_SB_.SCK0.CP00._OSC
>   arg0: 0x80620488 cnt:05 stk: 00 buffer: 10 {16, a6, 77, 40,
> 0c, 29, be, 47, 9e, bd, d8, 70, 58, 71, 39, 53}
>   arg1: 0x80627988 cnt:01 stk:00 integer: 1 arg2: 0x80629388 
> cnt:01 stk:00 integer: 2
>   arg3: 0x8061d188 cnt:04 stk:00 buffer: 0c {00, 00, 00, 00, 3b,
> 03, 00, 00, ff, ff, ff, ff}
> 034d Called: \_SB_.SCK0.CP00._OSC
>   arg0: 0x80620488 cnt:05 stk: 00 buffer: 10 {16, a6, 77, 40,
> 0c, 29, be, 47, 9e, bd, d8, 70, 58, 71, 39, 53}
>   arg1: 0x80627988 cnt:01 stk:00 integer: 1
>   arg2: 0x80629388 cnt:01 stk:00 integer: 2
>   arg3: 0x8061d188 cnt:04 stk:00 buffer: 0c {00, 00, 00, 00, 3b,
> 03, 00, 00, ff, ff, ff, ff}
> panic: aml_die aml_parse:4194
> 
> This is reproducible at every boot.  I've tried to boot bsd.rd and mount root 
> fs to
> run acpidump, but it just says Abort trap.
> 
> Disabling acpi in UKC gets me to different panic, but this is probably
> barking at wrong tree at this point. 
> 
> There's also MARVELL 88SE9230 AHCI driver with two SSD drives I don't
> need. Installer complains about port softreset, haven't tried the
> functionality yet. 
> 
> There are some performance settings in bios
> (https://synchronicity.cz/bsd/bios/IMG_20180430_150250.jpg) but random
> fiddling without understanding didn't help me at this point.
> 
> Is there anything else to help debug this? I should have this box for
> another week or so (2 weeks from this monday 30.4.). 
> 
> Cluestick please?
> 
> Thank you,
> Jan
> 
> ### Screenshots and boot video at: https://synchronicity.cz/bsd/ ; installer
> dmesg follows.
> 
> files:
> - https://synchronicity.cz/bsd/dmesg.txt # same as below
> - https://synchronicity.cz/bsd/openbsd%206.3-release.mp4 # boot
>   including BIOS for 6.3-release
> - https://synchronicity.cz/bsd/openbsd%20installer.mp4 # boot into
>   6.3-current installer
> - https://synchronicity.cz/bsd/panic%20bsd.mp%206.3-current.jpg # panic
>   with bsd.mp
> - https://synchronicity.cz/bsd/panic%20bsd.sp%206.3-curent.jpg # panic
>   with bsd.sp
> 
> 
> ### DMESG
> 
> OpenBSD 6.3-current (RAMDISK_CD) #12: Wed Apr 25 22:56:41 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 101524992000 (96821MB)
> avail mem = 98444308480 (93883MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x6cb09000 (62 entries)
> bios0: vendor Dell Inc. version "1.3.7" date 02/09/2018
> bios0: Dell Inc. PowerEdge R440
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP SSDT TPM2 WD__ HPET APIC MCFG MIGT MSCT NFIT PCAT 
> PCCT RASF SLIT SRAT SVOS OEM4 SSDT SSDT SSDT DMAR HEST BERT ERST EINJ
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 2494.65 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: cannot disable silicon debug
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at mainbus0: not configured
> cpu at 

6.3-current kernel panic: aml_die aml_parse:4194 on PowerEdge

[Jan Vlach]

R440 WAS( Re: Dell PowerEdge R430/R440 support)
Reply-To: 
In-Reply-To: <20180425150215.gh20...@diehard.n-r-g.com>

Hello misc@


the Dell PowerEdge R440 server arrived for testing and it panics on boot
to installed system. Installer works fine, it's the reboot into
installed system that fails. Both 6.3-release and 6.3-current behave the
same. (OpenBSD 6.3-current (RAMDISK_CD) #12: Wed Apr 25 22:56:41 MDT
2018; dmesg below)

I've turned PERC H330 into HBA mode and setup raid1 softraid from 3
disks.

last screen on monitor with panic (rewritten by hand, sorry for possible typos, 
photo at
https://synchronicity.cz/bsd/ )

### LAST PANIC SCREEN
acpiprt81 at acpi0: bus -1 (SR3A)
acpiprt82 at acpi0: bus -1 (SR3B)
acpiprt83 at acpi0: bus -1 (SR3C)
acpiprt84 at acpi0: bus -1 (SR3D)
acpiprt85 at acpi0: bus -1 (MCP6)
acpiprt86 at acpi0: bus -1 (MCP7)
acpicpu0 at acpi0LoadTable
0140 Called: \_SB_.SCK0.CP00.ISTT
0140 Called: \_SB_.SCK0.CP00.ISTT
034d Called: \_SB_.SCK0.CP00._OSC
  arg0: 0x80620488 cnt:05 stk: 00 buffer: 10 {16, a6, 77, 40,
0c, 29, be, 47, 9e, bd, d8, 70, 58, 71, 39, 53}
  arg1: 0x80627988 cnt:01 stk:00 integer: 1 arg2: 0x80629388 
cnt:01 stk:00 integer: 2
  arg3: 0x8061d188 cnt:04 stk:00 buffer: 0c {00, 00, 00, 00, 3b,
03, 00, 00, ff, ff, ff, ff}
034d Called: \_SB_.SCK0.CP00._OSC
  arg0: 0x80620488 cnt:05 stk: 00 buffer: 10 {16, a6, 77, 40,
0c, 29, be, 47, 9e, bd, d8, 70, 58, 71, 39, 53}
  arg1: 0x80627988 cnt:01 stk:00 integer: 1
  arg2: 0x80629388 cnt:01 stk:00 integer: 2
  arg3: 0x8061d188 cnt:04 stk:00 buffer: 0c {00, 00, 00, 00, 3b,
03, 00, 00, ff, ff, ff, ff}
panic: aml_die aml_parse:4194

This is reproducible at every boot.  I've tried to boot bsd.rd and mount root 
fs to
run acpidump, but it just says Abort trap.

Disabling acpi in UKC gets me to different panic, but this is probably
barking at wrong tree at this point. 

There's also MARVELL 88SE9230 AHCI driver with two SSD drives I don't
need. Installer complains about port softreset, haven't tried the
functionality yet. 

There are some performance settings in bios
(https://synchronicity.cz/bsd/bios/IMG_20180430_150250.jpg) but random
fiddling without understanding didn't help me at this point.

Is there anything else to help debug this? I should have this box for
another week or so (2 weeks from this monday 30.4.). 

Cluestick please?

Thank you,
Jan

### Screenshots and boot video at: https://synchronicity.cz/bsd/ ; installer
dmesg follows.

files:
- https://synchronicity.cz/bsd/dmesg.txt # same as below
- https://synchronicity.cz/bsd/openbsd%206.3-release.mp4 # boot
  including BIOS for 6.3-release
- https://synchronicity.cz/bsd/openbsd%20installer.mp4 # boot into
  6.3-current installer
- https://synchronicity.cz/bsd/panic%20bsd.mp%206.3-current.jpg # panic
  with bsd.mp
- https://synchronicity.cz/bsd/panic%20bsd.sp%206.3-curent.jpg # panic
  with bsd.sp


### DMESG

OpenBSD 6.3-current (RAMDISK_CD) #12: Wed Apr 25 22:56:41 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 101524992000 (96821MB)
avail mem = 98444308480 (93883MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x6cb09000 (62 entries)
bios0: vendor Dell Inc. version "1.3.7" date 02/09/2018
bios0: Dell Inc. PowerEdge R440
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT TPM2 WD__ HPET APIC MCFG MIGT MSCT NFIT PCAT PCCT 
RASF SLIT SRAT SVOS OEM4 SSDT SSDT SSDT DMAR HEST BERT ERST EINJ
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 2494.65 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: cannot disable silicon debug
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at 

aesni/crypto related kernel panic on 6.3

[mabi]

Hi,

I finally replaced my old OpenBSD 5.0 firewall with 6.3 which also serves as a 
site-to-site VPN using now iked instead of isakmpd. The problem is that when I 
start a big transfer over the VPN to the remote site, also an OpenBSD 6.3 
firewall, the kernel panics. Crazy enough I tried to reproduce the problem to 
find out what it is related to and managed to even make both firewalls kernel 
panic at the same time. When this happens the hardware is frozen and won't take 
any input and won't even reboot automatically. I need to power it off and on 
again.

As I was logged into the serial console when I reproduced this problem I 
managed to get the following messages from the console:

fatal protection fault in supervisor mode
trap type 4 code 0 rip 8104d58a cs 8 rflags 10202 cr2  1dd9ec5f7c70 cpl 
a rsp 80002231ce28
panic: trap type 4, code=0, pc=8104d58a
Starting stack trace...
panic() at panic+0x11c
trap() at trap+0x688
--- trap (number 4) ---
memcpy(801be460,ff03a0f34188,0,0,16,a21ae232a3847235) at memcpy+0xa
aesni_process(ff03a0f34188) at aesni_process+0x124
crypto_invoke(8116ebc0) at crypto_invoke+0xd0
taskq_thread(0) at taskq_thread+0x67
end trace frame: 0x0, count: 251
End of stack trace.
syncing disks... 

​When this happened I just started to transfer over SSH a ZFS snapshot to the 
remote site using the IPSec VPN. The iked daemon was rekeying its SAs and then 
the kernel paniced...

Below I pasted the dmesg of the firewall corresponding to the kernel panic 
message above. I can't send now the dmesg of the remote firewall as I need to 
go on-site first. Please let me know if I should send any log files or other 
details.

Regards,
Mabi


OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17104490496 (16312MB)
avail mem = 16579031040 (15810MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec1e0 (85 entries)
bios0: vendor American Megatrends Inc. version "4.6.5" date 02/05/2015
bios0: INTEL Corporation DENLOW_REFRESH_WS
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG HPET SSDT SSDT ASF! SPCR 
DMAR EINJ ERST HEST BERT
acpi0: wakeup devices PEGP(S0) PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0) 
PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) 
PXSX(S0) RP05(S0) [...]
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) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3691.99 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpitimer0: recalibrated TSC frequency 3491911605 Hz
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, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3691.45 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,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) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3691.45 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,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) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3691.45 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,

Re: OpenBSD 6.3 kernel panic

[Juan Morado]

On Sun, Apr 15, 2018 at 1:02 AM, Mike Larkin  wrote:

> On Sat, Apr 14, 2018 at 11:32:00PM -0500, Juan Morado wrote:
> > Here's the text as best I can see it.
> >
> > uvm_fault (0xc1afca80, 0x808ca000, 0, 1) -> e
> > kernel: page fault trap, code=0
> > Stopped atihidev_intr+0x18a:  movzbl   0(%rsi,%rax,1),%eax
> > ddb{0}>
> >
> > On the same hardware, I did occasionally get some errors logged to the
> > console running 6.2, IIRC something about an invalid value from ihiddev,
> > but it didn't crash or hang.
> >
>
> Can you show the output of "show reg" at ddb?
>
> PS, this bug report leaves a lot to be desired...
>

https://www.openbsd.org/report.html

I think responding with the link above would have been most gracious.
I'll try to get all that information together and take the discussion over
to b...@openbsd.org Thanks for the help thus far.

Re: OpenBSD 6.3 kernel panic

[IL Ka]

Technically, you can debug your real machine kernel using serial (aka com)
port, but I do not think you need to do that.
When your kernel panics, it takes your to ddb, right?

You got "uvm_fault  page fault trap": it means kernel tries to access some
invalid memory address.
It happens in  "ihidev_intr" (HID-over-i2c driver) at offset 0x18a.
This address is stored in registry, that is why Mike Larkin aksed you to do
"show reg": get registers values, and send them to list.

So, there is some bug in ihidev_intr driver, you need to post whole
text + "show
reg" output to bugs@ along with your laptop name.




On Mon, Apr 16, 2018 at 4:13 AM, Juan Morado  wrote:

> Rupert, that's a great article, thanks for sharing. I don't see how that
> helps when my OpenBSD host machine would crash (not the QEMU guest) when I
> so much as touch the track pad.
>
> On Sun, Apr 15, 2018 at 2:05 AM, Rupert Gallagher 
> wrote:
>
> > http://bijanebrahimi.github.io/blog/remote-debugging-the-
> > running-openbsd-kernel.html
> >
> > On Sun, Apr 15, 2018 at 08:02, Mike Larkin  wrote:
> >
> > PS, this bug report leaves a lot to be desired... -ml
> >
> >
>

Re: OpenBSD 6.3 kernel panic

[Juan Morado]

Rupert, that's a great article, thanks for sharing. I don't see how that
helps when my OpenBSD host machine would crash (not the QEMU guest) when I
so much as touch the track pad.

On Sun, Apr 15, 2018 at 2:05 AM, Rupert Gallagher 
wrote:

> http://bijanebrahimi.github.io/blog/remote-debugging-the-
> running-openbsd-kernel.html
>
> On Sun, Apr 15, 2018 at 08:02, Mike Larkin  wrote:
>
> PS, this bug report leaves a lot to be desired... -ml
>
>

Re: OpenBSD 6.3 kernel panic

[Rupert Gallagher]

http://bijanebrahimi.github.io/blog/remote-debugging-the-running-openbsd-kernel.html

On Sun, Apr 15, 2018 at 08:02, Mike Larkin  wrote:

> PS, this bug report leaves a lot to be desired... -ml

Re: OpenBSD 6.3 kernel panic

[Mike Larkin]

On Sat, Apr 14, 2018 at 11:32:00PM -0500, Juan Morado wrote:
> Here's the text as best I can see it.
> 
> uvm_fault (0xc1afca80, 0x808ca000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped atihidev_intr+0x18a:  movzbl   0(%rsi,%rax,1),%eax
> ddb{0}>
> 
> On the same hardware, I did occasionally get some errors logged to the
> console running 6.2, IIRC something about an invalid value from ihiddev,
> but it didn't crash or hang.
> 

Can you show the output of "show reg" at ddb?

PS, this bug report leaves a lot to be desired...

-ml

> On Sat, Apr 14, 2018 at 8:06 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > On Sat, Apr 14, 2018 at 04:47:32PM -0500, Juan Morado wrote:
> > > On Fri, Apr 13, 2018 at 1:18 PM, Mike Larkin <mlar...@azathoth.net>
> > wrote:
> > >
> > > > On Thu, Apr 12, 2018 at 10:19:23PM -0500, Juan Morado wrote:
> > > > > Hi all,
> > > > >
> > > > > I searched the mail archives briefly but couldn't find a related
> > issue.
> > > > > Apologies if this is a duplicate.
> > > > >
> > > > > Since upgrading to OpenBSD 6.3 on my amd64 laptop, it has been
> > crashing
> > > > > whenever I touch the track pad.
> > > > >
> > > > > Touching the track pad after X starts generally causes the machine to
> > > > just
> > > > > hang, however, it also crashes during boot if the track pad is
> > touched
> > > > so I
> > > > > was able to get a dump from ddb.
> > > > >
> > > > > Output from dmesg follows. I also have bsd.0.core, bsd.0, bounds,
> > minfree
> > > > > files from the crash dump. If there is any interest in looking at
> > these,
> > > > > please advise the best way to share them.
> > > > >
> > > > > - JM
> > > > >
> > > > > ---
> > > >
> > > > Where's the panic string?
> > > >
> > >
> > > Hell if I know.
> > >
> > > Maybe kernel panic isn't the correct terminology? ddb is invoked anytime
> > I
> >
> > So what does it say on the screen when you are in ddb?
> >
> > > touch the track pad while booting. Touching the track pad once X starts
> > > causes the machine to become unresponsive. I don't recall if the dmesg
> > was
> > > taken immediately following the crash or not. As I mentioned I was able
> > to
> > > generate a dump and I can share those dump files.
> >
> >
> >

Re: OpenBSD 6.3 kernel panic

[Juan Morado]

Here's the text as best I can see it.

uvm_fault (0xc1afca80, 0x808ca000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped atihidev_intr+0x18a:  movzbl   0(%rsi,%rax,1),%eax
ddb{0}>

On the same hardware, I did occasionally get some errors logged to the
console running 6.2, IIRC something about an invalid value from ihiddev,
but it didn't crash or hang.

On Sat, Apr 14, 2018 at 8:06 PM, Mike Larkin <mlar...@azathoth.net> wrote:

> On Sat, Apr 14, 2018 at 04:47:32PM -0500, Juan Morado wrote:
> > On Fri, Apr 13, 2018 at 1:18 PM, Mike Larkin <mlar...@azathoth.net>
> wrote:
> >
> > > On Thu, Apr 12, 2018 at 10:19:23PM -0500, Juan Morado wrote:
> > > > Hi all,
> > > >
> > > > I searched the mail archives briefly but couldn't find a related
> issue.
> > > > Apologies if this is a duplicate.
> > > >
> > > > Since upgrading to OpenBSD 6.3 on my amd64 laptop, it has been
> crashing
> > > > whenever I touch the track pad.
> > > >
> > > > Touching the track pad after X starts generally causes the machine to
> > > just
> > > > hang, however, it also crashes during boot if the track pad is
> touched
> > > so I
> > > > was able to get a dump from ddb.
> > > >
> > > > Output from dmesg follows. I also have bsd.0.core, bsd.0, bounds,
> minfree
> > > > files from the crash dump. If there is any interest in looking at
> these,
> > > > please advise the best way to share them.
> > > >
> > > > - JM
> > > >
> > > > ---
> > >
> > > Where's the panic string?
> > >
> >
> > Hell if I know.
> >
> > Maybe kernel panic isn't the correct terminology? ddb is invoked anytime
> I
>
> So what does it say on the screen when you are in ddb?
>
> > touch the track pad while booting. Touching the track pad once X starts
> > causes the machine to become unresponsive. I don't recall if the dmesg
> was
> > taken immediately following the crash or not. As I mentioned I was able
> to
> > generate a dump and I can share those dump files.
>
>
>

Re: OpenBSD 6.3 kernel panic

[Mike Larkin]

On Sat, Apr 14, 2018 at 04:47:32PM -0500, Juan Morado wrote:
> On Fri, Apr 13, 2018 at 1:18 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > On Thu, Apr 12, 2018 at 10:19:23PM -0500, Juan Morado wrote:
> > > Hi all,
> > >
> > > I searched the mail archives briefly but couldn't find a related issue.
> > > Apologies if this is a duplicate.
> > >
> > > Since upgrading to OpenBSD 6.3 on my amd64 laptop, it has been crashing
> > > whenever I touch the track pad.
> > >
> > > Touching the track pad after X starts generally causes the machine to
> > just
> > > hang, however, it also crashes during boot if the track pad is touched
> > so I
> > > was able to get a dump from ddb.
> > >
> > > Output from dmesg follows. I also have bsd.0.core, bsd.0, bounds, minfree
> > > files from the crash dump. If there is any interest in looking at these,
> > > please advise the best way to share them.
> > >
> > > - JM
> > >
> > > ---
> >
> > Where's the panic string?
> >
> 
> Hell if I know.
> 
> Maybe kernel panic isn't the correct terminology? ddb is invoked anytime I

So what does it say on the screen when you are in ddb?

> touch the track pad while booting. Touching the track pad once X starts
> causes the machine to become unresponsive. I don't recall if the dmesg was
> taken immediately following the crash or not. As I mentioned I was able to
> generate a dump and I can share those dump files.

Re: OpenBSD 6.3 kernel panic

[IL Ka]

>
> Maybe kernel panic isn't the correct terminology? ddb is invoked anytime I
> touch the track pad while booting.

 You are right: it is kernel panic.

Accroding to ddb(4):
"ddb is invoked upon a kernel panic when the sysctl(8) ddb.panic is set to
1."

I am not sure, but I believe you can disable it and get kernel panic
message on console instead of ddb by disabling this option in
"/etc/sysctl.conf" and reboot
But even with ddb you can get some useful information to report to bugs@.
See https://www.openbsd.org/ddb.html
I think "traceback" and "show panic" could be useful

Re: OpenBSD 6.3 kernel panic

[Juan Morado]

On Fri, Apr 13, 2018 at 1:18 PM, Mike Larkin <mlar...@azathoth.net> wrote:

> On Thu, Apr 12, 2018 at 10:19:23PM -0500, Juan Morado wrote:
> > Hi all,
> >
> > I searched the mail archives briefly but couldn't find a related issue.
> > Apologies if this is a duplicate.
> >
> > Since upgrading to OpenBSD 6.3 on my amd64 laptop, it has been crashing
> > whenever I touch the track pad.
> >
> > Touching the track pad after X starts generally causes the machine to
> just
> > hang, however, it also crashes during boot if the track pad is touched
> so I
> > was able to get a dump from ddb.
> >
> > Output from dmesg follows. I also have bsd.0.core, bsd.0, bounds, minfree
> > files from the crash dump. If there is any interest in looking at these,
> > please advise the best way to share them.
> >
> > - JM
> >
> > ---
>
> Where's the panic string?
>

Hell if I know.

Maybe kernel panic isn't the correct terminology? ddb is invoked anytime I
touch the track pad while booting. Touching the track pad once X starts
causes the machine to become unresponsive. I don't recall if the dmesg was
taken immediately following the crash or not. As I mentioned I was able to
generate a dump and I can share those dump files.

Re: OpenBSD 6.3 kernel panic

[Mike Larkin]

On Thu, Apr 12, 2018 at 10:19:23PM -0500, Juan Morado wrote:
> Hi all,
> 
> I searched the mail archives briefly but couldn't find a related issue.
> Apologies if this is a duplicate.
> 
> Since upgrading to OpenBSD 6.3 on my amd64 laptop, it has been crashing
> whenever I touch the track pad.
> 
> Touching the track pad after X starts generally causes the machine to just
> hang, however, it also crashes during boot if the track pad is touched so I
> was able to get a dump from ddb.
> 
> Output from dmesg follows. I also have bsd.0.core, bsd.0, bounds, minfree
> files from the crash dump. If there is any interest in looking at these,
> please advise the best way to share them.
> 
> - JM
> 
> ---

Where's the panic string?

> 
> OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4157906944 (3965MB)
> avail mem = 4024819712 (3838MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeced0 (18 entries)
> bios0: vendor American Megatrends Inc. version "X541SA.301" date 09/14/2016
> bios0: ASUSTeK COMPUTER INC. X541SA
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT ECDT MCFG SSDT SSDT SSDT UEFI LPIT
> TPM2 CSRT SSDT SSDT MSDM
> acpi0: wakeup devices BRC1(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4)
> RP02(S4) PXSX(S4) RP03(S4) SLPB(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) Pentium(R) CPU N3710 @ 1.60GHz, 1680.32 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> acpitimer0: recalibrated TSC frequency 1599952018 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 80MHz
> 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) Pentium(R) CPU N3710 @ 1.60GHz, 1680.01 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> 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) Pentium(R) CPU N3710 @ 1.60GHz, 1600.01 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> 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) Pentium(R) CPU N3710 @ 1.60GHz, 1600.01 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
> acpiec0 at acpi0
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus -1 (RP02)
> acpiprt3 at acpi0: bus 2 (RP03)
> acpiprt4 at acpi0: bus 3 (RP04)
> acpiec at acpi0 not configured
> acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: ID3C, resource for ISP3
> acpipwrres1 at acpi0: CLK0
> acpipwrres2 at acpi0: CLK0
> acpipwrres3 at acpi0: CLK1
> acpipwrres4 at acpi0: USBC, resource for XHC1
> acpipwrres5 at acpi0: FN00, resource for FAN0
> acpitz0 at acpi0: critical temperature is 95 degC
> acpitz1 at acpi0: critical temperature is 94 degC
> "ATK3001" at acpi0 not configured
> "INTL9C60" at acpi0 not configured
> dwiic0 at acpi0: I2C4 addr 0x8141c000/0x1000 irq 35
> iic0 at dwiic0
> ihidev0 at iic0 addr 0x15 irq 0, vendor 0xb05 

OpenBSD 6.3 kernel panic

[Juan Morado]

Hi all,

I searched the mail archives briefly but couldn't find a related issue.
Apologies if this is a duplicate.

Since upgrading to OpenBSD 6.3 on my amd64 laptop, it has been crashing
whenever I touch the track pad.

Touching the track pad after X starts generally causes the machine to just
hang, however, it also crashes during boot if the track pad is touched so I
was able to get a dump from ddb.

Output from dmesg follows. I also have bsd.0.core, bsd.0, bounds, minfree
files from the crash dump. If there is any interest in looking at these,
please advise the best way to share them.

- JM

---

OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4157906944 (3965MB)
avail mem = 4024819712 (3838MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xeced0 (18 entries)
bios0: vendor American Megatrends Inc. version "X541SA.301" date 09/14/2016
bios0: ASUSTeK COMPUTER INC. X541SA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT ECDT MCFG SSDT SSDT SSDT UEFI LPIT
TPM2 CSRT SSDT SSDT MSDM
acpi0: wakeup devices BRC1(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) SLPB(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) Pentium(R) CPU N3710 @ 1.60GHz, 1680.32 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
acpitimer0: recalibrated TSC frequency 1599952018 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 80MHz
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) Pentium(R) CPU N3710 @ 1.60GHz, 1680.01 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
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) Pentium(R) CPU N3710 @ 1.60GHz, 1600.01 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
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) Pentium(R) CPU N3710 @ 1.60GHz, 1600.01 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,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus 2 (RP03)
acpiprt4 at acpi0: bus 3 (RP04)
acpiec at acpi0 not configured
acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: ID3C, resource for ISP3
acpipwrres1 at acpi0: CLK0
acpipwrres2 at acpi0: CLK0
acpipwrres3 at acpi0: CLK1
acpipwrres4 at acpi0: USBC, resource for XHC1
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 95 degC
acpitz1 at acpi0: critical temperature is 94 degC
"ATK3001" at acpi0 not configured
"INTL9C60" at acpi0 not configured
dwiic0 at acpi0: I2C4 addr 0x8141c000/0x1000 irq 35
iic0 at dwiic0
ihidev0 at iic0 addr 0x15 irq 0, vendor 0xb05 product 0x201, FTE1200
ihidev0: 14 report ids
imt0 at ihidev0: clickpad, 5 contacts
wsmouse0 at imt0 mux 0
acpiac0 at acpi0: AC unit offline
acpibat0 at acpi0: BAT0 model "X550A26" serial   type LIon oem "ASUSTeK"
chvgpio0 at acpi0: GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins

Re: kernel panic with cmp

[Krzysztof Strzeszewski]

Hardware was bad, now it's ok.


W dniu 17.02.2018 o 08:23, Krzysztof Strzeszewski pisze:
> Hi,
>
> I have kernel panic in OpenBSD 6.1 end 6.2 on the same machine. Command
> "cmp" is in my script , it starts every minute. When I don't use "cmp"
> command with my script, is ok. This kernel panic is after the last path
> of February 2, 2018. Kernel is default from upgrade.
>
>
> Links:
>
> #--
>
> https://nroot.pl/kernel/kernel_panic_openbsd_6.1.JPG
>
> https://nroot.pl/kernel/kernel_panic_openbsd_6.2.JPG
>
> https://nroot.pl/kernel/mem_test.JPG
>
> #--
>
>
> 
> Regards,
> Krzych
>
>
>

kernel panic with cmp

[Krzysztof Strzeszewski]

Hi,

I have kernel panic in OpenBSD 6.1 end 6.2 on the same machine. Command
"cmp" is in my script , it starts every minute. When I don't use "cmp"
command with my script, is ok. This kernel panic is after the last path
of February 2, 2018. Kernel is default from upgrade.


Links:

#--

https://nroot.pl/kernel/kernel_panic_openbsd_6.1.JPG

https://nroot.pl/kernel/kernel_panic_openbsd_6.2.JPG

https://nroot.pl/kernel/mem_test.JPG

#--



Regards,
Krzych

Re: Kernel panic with openbsd 6.2

[Tom Smyth]

Hello lads,

I have about 15 OpenBSD 6.x servers 4x 6.2 servers on
Vmware and  vmxnet net drivers,
Im running on Vmware 6.0 Update 2
( the earlier vmware 6.0 with out updates was very problmeatic)
I dont do much on Snapshots,
but I use a LSI Logic Paralell Storage Driver (SCSI)
and vmxnet3
I havent encountered any kernel panics
(when I create the VM I use the Freebsd 64 Bit OS as the installed OS
setting in vmware)
 and amd64 OpenBSD
Im using Vm virtual hardware version 11

the Nics on physical servers are a mix between Broadcom Netxtreme and
intel pro 1000

I hope this helps

Tom Smyth


On 25 January 2018 at 21:08, Rupert Gallagher <r...@protonmail.com> wrote:
> esxi 5.5.0 dates back to 2013.
> obsd runs better on qemu nowadays.
> To avoid the mess with x86/amd64,
> perhaps qemu-sparc with obsd-sparc
> will serve you better.
>
> Sent from ProtonMail Mobile
>
> On Fri, Jan 19, 2018 at 21:50, Mik J <mikyde...@yahoo.fr> wrote:
>
>> Hello, I had many kernel panic these past days. This is a 6.2 openbsd VM 
>> running on esxi 5.5

Re: Kernel panic with openbsd 6.2

[Rupert Gallagher]

esxi 5.5.0 dates back to 2013.
obsd runs better on qemu nowadays.
To avoid the mess with x86/amd64,
perhaps qemu-sparc with obsd-sparc
will serve you better.

Sent from ProtonMail Mobile

On Fri, Jan 19, 2018 at 21:50, Mik J <mikyde...@yahoo.fr> wrote:

> Hello, I had many kernel panic these past days. This is a 6.2 openbsd VM 
> running on esxi 5.5

Re: Kernel panic with openbsd 6.2

[trondd]

On Thu, January 25, 2018 4:29 am, Maxim Bourmistrov wrote:
> As Stuart mentioned, em(4) on top of e1000 proven to be more stable.
> Even under higher load.
> Vmx starting to misbehave under high load, resulting for ex. with unstable
> CARP setup.
>
> //mxb
>
>> 25 jan. 2018 kl. 02:40 skrev trondd :
>>
>> I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
>> one VM that panics with vmxnet3_getbuf but only when it's being
>> snapshotted.  And not every time, but usually.
>>
>> I think once it paniced when I was snapshotting a lot of other VMs in
>> the
>> cluster but I don't trust that memory now.  I've not seen that again.
>>
>> Tim.
>>
>

I should have also said that these VMs all run postgreSQL servers.  The
busiest nears 200 simultanious connections which may be well below the
load other's are handling on their effected systems.

Tim.

Re: Kernel panic with openbsd 6.2

[Maxim Bourmistrov]

As Stuart mentioned, em(4) on top of e1000 proven to be more stable.
Even under higher load.
Vmx starting to misbehave under high load, resulting for ex. with unstable CARP 
setup.

//mxb

> 25 jan. 2018 kl. 02:40 skrev trondd <tro...@kagu-tsuchi.com>:
> 
> On Mon, January 22, 2018 10:47 am, Mik J wrote:
>> Hello Stuart,
>> For me it takes just a few days...
>> I have a crash every 3/4 days maybe (2 crashes so far) and my server does
>> not handle load.
>> Yes I read your reports this morning, although you wrote that there was a
>> combination with snmpd, I have it with nginx on my side.
>> 
>> Regards
>> 
>>Le lundi 22 janvier 2018 Ã
 10:35:47 UTC+1, Stuart Henderson
>> <s...@spacehopper.org> a écrit :
>> 
>> On 2018/01/22 00:22, Mik J wrote:
>>> Le dimanche 21 janvier 2018 Ã
 11:48:00 UTC+1, Stuart Henderson
>>> <s...@spacehopper.org> a écrit :
>>> On 2018-01-19, Mik J <mikyde...@yahoo.fr> wrote:
>>>> I had many kernel panic these past days. This is a 6.2 openbsd VM
>>> running o=
>>>> n esxi 5.5
>>>> 
>>>> # grep "" /tmp/if_vmx.dis
>>> 
>>> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
>>> I suggest switching to e1000 in the vmx file, this works with the em(4)
>>> driver and has been stable so far.
>>> 
>>> 
>>> Hello Stuart,
>>> Thank you for your answer.
>>> I had my VM running for months in version 6.1 and had not problem but I
>>> reinstalled it in
>>> version 6.2 and the problem is happening.
>>> It seems to me that something in version 6.2 is producing the error.
>>> One crash today again
>> 
>> I hit this in last April, which was either 6.1 or -current from soon
>> after.
>> It can take weeks to run into it though so bisecting to find a working
>> kernel
>> is futile.
>> 
>> 
> 
> I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
> one VM that panics with vmxnet3_getbuf but only when it's being
> snapshotted.  And not every time, but usually.
> 
> I think once it paniced when I was snapshotting a lot of other VMs in the
> cluster but I don't trust that memory now.  I've not seen that again.
> 
> Tim.
> 

Re: Kernel panic with openbsd 6.2

[trondd]

On Mon, January 22, 2018 10:47 am, Mik J wrote:
> Hello Stuart,
> For me it takes just a few days...
> I have a crash every 3/4 days maybe (2 crashes so far) and my server does
> not handle load.
> Yes I read your reports this morning, although you wrote that there was a
> combination with snmpd, I have it with nginx on my side.
>
>  Regards
>
> Le lundi 22 janvier 2018 Ã
 10:35:47 UTC+1, Stuart Henderson
> <s...@spacehopper.org> a écrit :
>
>  On 2018/01/22 00:22, Mik J wrote:
>> Le dimanche 21 janvier 2018 Ã
 11:48:00 UTC+1, Stuart Henderson
>> <s...@spacehopper.org> a écrit :
>> On 2018-01-19, Mik J <mikyde...@yahoo.fr> wrote:
>> > I had many kernel panic these past days. This is a 6.2 openbsd VM
>> running o=
>> > n esxi 5.5
>> >
>> > # grep "" /tmp/if_vmx.dis
>>
>> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
>> I suggest switching to e1000 in the vmx file, this works with the em(4)
>> driver and has been stable so far.
>>
>>
>> Hello Stuart,
>> Thank you for your answer.
>> I had my VM running for months in version 6.1 and had not problem but I
>> reinstalled it in
>> version 6.2 and the problem is happening.
>> It seems to me that something in version 6.2 is producing the error.
>> One crash today again
>
> I hit this in last April, which was either 6.1 or -current from soon
> after.
> It can take weeks to run into it though so bisecting to find a working
> kernel
> is futile.
>
>

I am running about a dozen 6.2 -stable VMs on ESXi 6.5.  I have exactly
one VM that panics with vmxnet3_getbuf but only when it's being
snapshotted.  And not every time, but usually.

I think once it paniced when I was snapshotting a lot of other VMs in the
cluster but I don't trust that memory now.  I've not seen that again.

Tim.

Re: Kernel panic with openbsd 6.2

[Stuart Henderson]

On 2018-01-24, who one <whoonet...@mail.com> wrote:
> Could it be related to: 
> https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

No.


> ?
>
>> Sent: Friday, January 19, 2018 at 9:50 PM
>> From: "Mik J" <mikyde...@yahoo.fr>
>> To: Misc <misc@openbsd.org>
>> Subject: Kernel panic with openbsd 6.2
>>
>> Hello,
>> 
>> I had many kernel panic these past days. This is a 6.2 openbsd VM running on 
>> esxi 5.5
>> 
>> I took screenshots then followed
>> https://www.openbsd.org/ddb.html
>> 
>> # objdump -dlr /sys/arch/amd64/compile/GENERIC.MP/obj/if_vmx.o > 
>> /tmp/if_vmx.dis
>> 
>> # grep "" /tmp/if_vmx.dis
>>     10f6:   e8 d5 00 00 00  callq  11d0 
>>     1176:   e8 55 00 00 00  callq  11d0 
>> 11d0 :
>>     1857:   e8 74 f9 ff ff  callq  11d0 
>> 
>> # grep -n 10f6 /tmp/if_vmx.dis
>> 1667:    10f6:  e8 d5 00 00 00  callq  11d0 
>> 
>> # grep ":" /tmp/if_vmx.dis
>> 11d0 :
>> 
>> # printf '%x\n' $((0x11d0 + 0x263))
>> 1433
>> 
>> vi /tmp/if_vmx.dis
>>    2040 1433:   ba 01 00 00 00  mov    $0x1,%edx
>> I find is on line 2040
>> 
>> => But the file is only 1251 line long
>> nl -ba /sys/dev/pci/if_vmx.c | sed -n 2040p
>> 
>> => So that last command gives me nothing
>> 
>> Do you have an idea of what mistake I did so that I can make a report ?
>> 
>> Thank you
>> 
>>
>
>

Re: Kernel panic with openbsd 6.2

[who one]

Could it be related to: 
https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

?

> Sent: Friday, January 19, 2018 at 9:50 PM
> From: "Mik J" <mikyde...@yahoo.fr>
> To: Misc <misc@openbsd.org>
> Subject: Kernel panic with openbsd 6.2
>
> Hello,
> 
> I had many kernel panic these past days. This is a 6.2 openbsd VM running on 
> esxi 5.5
> 
> I took screenshots then followed
> https://www.openbsd.org/ddb.html
> 
> # objdump -dlr /sys/arch/amd64/compile/GENERIC.MP/obj/if_vmx.o > 
> /tmp/if_vmx.dis
> 
> # grep "" /tmp/if_vmx.dis
>     10f6:   e8 d5 00 00 00  callq  11d0 
>     1176:   e8 55 00 00 00  callq  11d0 
> 11d0 :
>     1857:   e8 74 f9 ff ff  callq  11d0 
> 
> # grep -n 10f6 /tmp/if_vmx.dis
> 1667:    10f6:  e8 d5 00 00 00  callq  11d0 
> 
> # grep ":" /tmp/if_vmx.dis
> 11d0 :
> 
> # printf '%x\n' $((0x11d0 + 0x263))
> 1433
> 
> vi /tmp/if_vmx.dis
>    2040 1433:   ba 01 00 00 00  mov    $0x1,%edx
> I find is on line 2040
> 
> => But the file is only 1251 line long
> nl -ba /sys/dev/pci/if_vmx.c | sed -n 2040p
> 
> => So that last command gives me nothing
> 
> Do you have an idea of what mistake I did so that I can make a report ?
> 
> Thank you
> 
>

Re: Kernel panic with openbsd 6.2

[Mik J]

Hello Stuart,
For me it takes just a few days...
I have a crash every 3/4 days maybe (2 crashes so far) and my server does not 
handle load.
Yes I read your reports this morning, although you wrote that there was a 
combination with snmpd, I have it with nginx on my side.

 Regards

Le lundi 22 janvier 2018 à 10:35:47 UTC+1, Stuart Henderson 
<s...@spacehopper.org> a écrit :  
 
 On 2018/01/22 00:22, Mik J wrote:
> Le dimanche 21 janvier 2018 à 11:48:00 UTC+1, Stuart Henderson 
> <s...@spacehopper.org> a écrit :
> On 2018-01-19, Mik J <mikyde...@yahoo.fr> wrote:
> > I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> > n esxi 5.5
> >
> > # grep "" /tmp/if_vmx.dis
> 
> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
> I suggest switching to e1000 in the vmx file, this works with the em(4)
> driver and has been stable so far.
> 
> 
> Hello Stuart,
> Thank you for your answer.
> I had my VM running for months in version 6.1 and had not problem but I 
> reinstalled it in
> version 6.2 and the problem is happening.
> It seems to me that something in version 6.2 is producing the error.
> One crash today again

I hit this in last April, which was either 6.1 or -current from soon after.
It can take weeks to run into it though so bisecting to find a working kernel
is futile.

  

Re: Kernel panic with openbsd 6.2

[Stuart Henderson]

On 2018/01/22 00:22, Mik J wrote:
> Le dimanche 21 janvier 2018 à 11:48:00 UTC+1, Stuart Henderson 
> <s...@spacehopper.org> a écrit :
> On 2018-01-19, Mik J <mikyde...@yahoo.fr> wrote:
> > I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> > n esxi 5.5
> >
> > # grep "" /tmp/if_vmx.dis
> 
> I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
> I suggest switching to e1000 in the vmx file, this works with the em(4)
> driver and has been stable so far.
> 
> 
> Hello Stuart,
> Thank you for your answer.
> I had my VM running for months in version 6.1 and had not problem but I 
> reinstalled it in
> version 6.2 and the problem is happening.
> It seems to me that something in version 6.2 is producing the error.
> One crash today again

I hit this in last April, which was either 6.1 or -current from soon after.
It can take weeks to run into it though so bisecting to find a working kernel
is futile.

Re: Kernel panic with openbsd 6.2

[Mik J]

Hello Stuart,Thank you for your answer.I had my VM running for months in 
version 6.1 and had not problem but I reinstalled it in version 6.2 and the 
problem is happening.It seems to me that something in version 6.2 is producing 
the error.One crash today again
 

Le dimanche 21 janvier 2018 à 11:48:00 UTC+1, Stuart Henderson 
<s...@spacehopper.org> a écrit :  
 
 On 2018-01-19, Mik J <mikyde...@yahoo.fr> wrote:
> I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> n esxi 5.5
>
> # grep "" /tmp/if_vmx.dis

I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
I suggest switching to e1000 in the vmx file, this works with the em(4)
driver and has been stable so far.


  

Re: Kernel panic with openbsd 6.2

[Stuart Henderson]

On 2018-01-19, Mik J <mikyde...@yahoo.fr> wrote:
> I had many kernel panic these past days. This is a 6.2 openbsd VM running o=
> n esxi 5.5
>
> # grep "" /tmp/if_vmx.dis

I've reported a lot of vmxnet3_getbuf panics, nobody seems interested.
I suggest switching to e1000 in the vmx file, this works with the em(4)
driver and has been stable so far.

Re: Apollo Lake kernel panic

[Pedro Ramos]

I cannot check it right now, but I am pretty sure I have disabled the C 
states and as well CSM. Also I have upgrade the firmware to the latest.
At the beginning I also had some troubles. The system was crashing at 
different times. Now it is stable. I am running 6.2 -current not Release.


Às 06:00 de 04/11/2017, Predrag Punosevac escreveu:

I copied the bsd.mp kernel from a working machine. Here is the dmesg.  I
also disabled C states in BIOS and was able cleanly to halt machine


OpenBSD 6.2 (GENERIC) #132: Tue Oct  3 21:18:21 MDT 2017
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 16799846400 (16021MB)
avail mem = 16283758592 (15529MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017
bios0: ASRock J4205-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP LPIT APIC NPKT PRAM WSMT SSDT 
SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BERT WDAT NHLT
acpi0: wakeup devices SIO1(S4) PS2K(S4) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
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) Pentium(R) CPU J4205 @ 1.50GHz, 1497.60 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,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 149760 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 
1000, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b
inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 
0x0b
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load 
firmware i915/bxt_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 
(ignored)
inteldrm0: 1440x900, 32bpp
Unclaimed register detected after writing to register 0x68980
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 14 function 0 vendor "Intel", unknown product 0x5a98 rev 
0x0b: msi
azalia0: codecs: Realtek/0x0892, 0x/0x, using Realtek/0x0892
audio0 at azalia0
vendor "Intel", unknown product 0x5a9a (class communications subclass 
miscellaneous, rev 0x0b) at pci0 dev 15 function 0 not configured
ahci0 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x5ae3 rev 
0x0b: msi, AHCI 1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c8afc
sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors
sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c72e9
sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
ppb0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x5ad8 rev 0xfb: 
msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G (0x4c00), 
msi, address 70:85:c2:4a:bf:5b
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb1 at pci0 dev 19 function 1 vendor "Intel", unknown product 0x5ad9 rev 0xfb: 
msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 19 function 2 vendor "Intel", unknown product 0x5ada rev 0xfb: 
msi
pci3 at ppb2 bus 3
ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI 1.2
ahci1: port 0: 1.5Gb/s
scsibus2 at ahci1: 32 

Re: Apollo Lake kernel panic

[Predrag Punosevac]

I copied the bsd.mp kernel from a working machine. Here is the dmesg.  I
also disabled C states in BIOS and was able cleanly to halt machine


OpenBSD 6.2 (GENERIC) #132: Tue Oct  3 21:18:21 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 16799846400 (16021MB)
avail mem = 16283758592 (15529MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017
bios0: ASRock J4205-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP LPIT APIC NPKT PRAM WSMT SSDT 
SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BERT WDAT NHLT
acpi0: wakeup devices SIO1(S4) PS2K(S4) HDAS(S3) XHC_(S4) XDCI(S4) BRCM(S0) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
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) Pentium(R) CPU J4205 @ 1.50GHz, 1497.60 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,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 149760 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 
1000, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b
inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 
0x0b
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load 
firmware i915/bxt_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 
(ignored)
inteldrm0: 1440x900, 32bpp
Unclaimed register detected after writing to register 0x68980
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 14 function 0 vendor "Intel", unknown product 0x5a98 rev 
0x0b: msi
azalia0: codecs: Realtek/0x0892, 0x/0x, using Realtek/0x0892
audio0 at azalia0
vendor "Intel", unknown product 0x5a9a (class communications subclass 
miscellaneous, rev 0x0b) at pci0 dev 15 function 0 not configured
ahci0 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x5ae3 rev 
0x0b: msi, AHCI 1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c8afc
sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors
sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c72e9
sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
ppb0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x5ad8 rev 0xfb: 
msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G (0x4c00), 
msi, address 70:85:c2:4a:bf:5b
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb1 at pci0 dev 19 function 1 vendor "Intel", unknown product 0x5ad9 rev 0xfb: 
msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 19 function 2 vendor "Intel", unknown product 0x5ada rev 0xfb: 
msi
pci3 at ppb2 bus 3
ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI 1.2
ahci1: port 0: 1.5Gb/s
scsibus2 at ahci1: 32 targets
cd0 at scsibus2 targ 0 lun 0:  ATAPI 5/cdrom 
removable
ppb3 at pci0 dev 19 function 3 vendor "Intel", unknown product 0x5adb rev 0xfb: 
msi
pci4 at ppb3 bus 4
xhci0 at pci0 dev 21 function 0 vendor "Intel", unknown product 0x5aa8 rev 
0x0b: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 

Re: Apollo Lake kernel panic

[Predrag Punosevac]

I was able to boot machine which crashed with bsd.sp kernel. Please see
message below. That kernel is non-patched kernel as I was running
normally bsd.mp kernel. Also I forgot to say in my previous message that
I didn't mess with C states (BIOS option). I was also using legacy (not
pure UEFI boot) as the the original installation was done on the system 
which didn't support UEFI boot.


OpenBSD 6.2 (GENERIC) #132: Tue Oct  3 21:18:21 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 16799846400 (16021MB)
avail mem = 16283758592 (15529MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017
bios0: ASRock J4205-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP LPIT APIC NPKT PRAM WSMT SSDT 
SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BERT WDAT NHLT
acpi0: wakeup devices SIO1(S4) PS2K(S4) UAR1(S4) HDAS(S3) XHC_(S4) XDCI(S4) 
BRCM(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
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) Pentium(R) CPU J4205 @ 1.50GHz, 1497.60 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,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 149760 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 
mwait.1@0x1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 
1000, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b
inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 
0x0b
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load 
firmware i915/bxt_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 
(ignored)
inteldrm0: 1440x900, 32bpp
Unclaimed register detected after writing to register 0x68980
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 14 function 0 vendor "Intel", unknown product 0x5a98 rev 
0x0b: msi
azalia0: codecs: Realtek/0x0892, 0x/0x, using Realtek/0x0892
audio0 at azalia0
vendor "Intel", unknown product 0x5a9a (class communications subclass 
miscellaneous, rev 0x0b) at pci0 dev 15 function 0 not configured
ahci0 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x5ae3 rev 
0x0b: msi, AHCI 1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c8afc
sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors
sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c72e9
sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
ppb0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x5ad8 rev 0xfb: 
msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G (0x4c00), 
msi, address 70:85:c2:4a:bf:5b
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb1 at pci0 dev 19 function 1 vendor "Intel", unknown product 0x5ad9 rev 0xfb: 
msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 19 function 2 vendor "Intel", unknown product 0x5ada rev 0xfb: 
msi
pci3 at ppb2 bus 3
ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI 1.2
ahci1: port 0: 1.5Gb/s
scsibus2 at ahci1: 32 targets
cd0 at scsibus2 targ 0 lun 0: 

Re: Apollo Lake kernel panic

[Predrag Punosevac]

Pedro Ramos wrote:

> Please find attached the dmesg from ASRock J4205-ITX.
> 
> 
> Best regards,
> Pedro Ramos
> 
> 
> ["asrock.j4205-itx.dmesg.gz" (application/x-gzip)]

Unfortunatelly I got one of those few weeks ago and it is nothing but
the trouble. The first one died but NewEgg sent me the second one. I
don't know where to begin. 

With the default ACPI configuration options

1. Suspend to RAM  enabled  
2. ACPI HPET Table enabled 

one can't clearly shut down 6.2 stable. This is what I got 

www.devio.us/~ppunosevac/kernel-panic-1.jpg

The system was frozen to the point that I could not get crash trace. 
With suspend to RAM and HPET table disabled I could finally do 

shutdown -p now

without crashing kernel.

I see that even on 6.2 current dmesg which was sent bunch of errors in
dmesg

pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0
rev 0x0b
inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product
0x5a84 rev 0x0b
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load
firmware i915/bxt_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC,
error -8 (ignored)


Unfortunatelly at this point my system is trashed so I can't post dmesg
from of 6.2 stable. Namely after trying to start Chrome I got kernel
panic again but I was able this time to trace it 

www.devio.us/~ppunosevac/kernel-panic-2.jpg
 
Now the system hangs on the boot with the message 

entry point at 0x1000158 

My boot device was RAID 1 and I would appreciate if somebody could give
me a suggestion if I can recover the system (I do have the backup for
data). 

Few more things. I could not get X running on my DVI-D 4:3 monitor.
However both VGA output and HDMI were working. HDMI had no problem using
my high definition Panasonic TV. 

If you attach HDD to ASMedia ASM1061 SATA ports (there are 2 of those
and there are two of SATA3 6.0Gb/s Connectors, support NCQ, AHCI and Hot
Plug) S.M.A.R.T. daemon will refuse to start. I have not investigated
this further.

Sound Realtek ALC892 did work as well as Realtek 8111GR Gigabit LAN.
I could not make a use of 1 x PCI Express 2.0 x1 Slot. Note also that
M.2 is only for WiFi not for storage device.

I am not feeling good about this purchase right now. Maybe somebody
could give me some pointers.

Best,
Predrag   

Re: kernel panic i386

[Philip Guenther]

On Sat, Oct 14, 2017 at 6:57 AM, Krzysztof Strzeszewski 
wrote:

> This is very interested "the kernel did non panic".


panic() is an explicit call in the kernel, made when some sanity or
consistency check fails.  Dereferencing a bogus pointer results in a failed
page fault trap and goes to ddb directly without going through panic(), so
there's no "panic message".

(Someone looking for a kernel change to hack on?  How about this: figure
out how to make ddb's "show panic" report something useful when you entered
ddb via a kernel page fault where uvm_fault() returned EFAULT.)



> Where is memcmp in sys? When I run bsd.rd end mount filesystem I can't
> find memcmp.
>

memcmp() is a function inside the kernel, so I'm not sure what your last
statement means.

...

> ddb> trace
> memcmp(d3182800,681,9,1b) at memcmp+0x11
> k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at
> k7_powernow_init+0xf8
> amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c
> mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e
> ...


This trace is kinda weird:  k7_powernow_init+0xf8 matches with it being a
call to k7pnow_states(), which does calls memcmp(), but where did the
intermediate stack frame go?  And why are the args to memcmp() so odd?

On top of it, nothing has really changed in the K7 code since 6.1, so the
only real change is the change in compilers from gcc to clang.  The
resulting object code is _substantially_ different: that clang doesn't
inline the memcmp() call is just one aspect.  Is there something in that
code which clang is deciding to optimize in ways that break it?

Philip Guenther

Re: kernel panic i386

[Krzysztof Strzeszewski]

This is very interested "the kernel did non panic". Where is memcmp in 
sys? When I run bsd.rd end mount filesystem I can't find memcmp.



http://wklej.org/hash/e5591ccc88f/

.
.
.
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c230c0, 0xd0f2f000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:    repe cmpsl  (%esi),%es:(%edi)


ddb> show panic
the kernel did not panic

ddb> trace
memcmp(d3182800,681,9,1b) at memcmp+0x11
k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at 
k7_powernow_i

nit+0xf8
amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c
mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e
config_attach(0,d0c0335c,0,0) at config_attach+0x184
config_rootfound(d09cb92c,0) at config_rootfound+0xc0
cpu_configure(944dfcd2,ec,ecf000,0,d02004ce) at cpu_configure+0x29
main(0,0,0,0,0) at main+0x478
ddb>




Regards,
Krzych


W dniu 14.10.2017 o 11:58, Philip Guenther pisze:
On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski 
<krz...@krzy.ch <mailto:krz...@krzy.ch>> wrote:


When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.


It's unfortunate that no one has submitted to dm...@openbsd.org 
<mailto:dm...@openbsd.org> the dmesg from that hardware since February 
2016.  Please consider doing so every time you upgrade your kernel, so 
that we have a record of what is working.


 ...

cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      memcmp+0x11:    repe cmpsl (%esi),%es:(%edi)
ddb>


https://www.openbsd.org/ddb.html

Without a backtrace, all we can see is that a copy operation in the 
kernel faulted, with no indication of *which* copy operation did so.



Philip Guenther

Re: kernel panic i386

[Philip Guenther]

On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski <krz...@krzy.ch>
wrote:

> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
>

It's unfortunate that no one has submitted to dm...@openbsd.org the dmesg
from that hardware since February 2016.  Please consider doing so every
time you upgrade your kernel, so that we have a record of what is working.

 ...

> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
> ddb>
>

 https://www.openbsd.org/ddb.html

Without a backtrace, all we can see is that a copy operation in the kernel
faulted, with no indication of *which* copy operation did so.


Philip Guenther

Re: kernel panic i386

[Krzysztof Strzeszewski]

I changed only name kernel :)


W dniu 14.10.2017 o 01:13, Mike Larkin pisze:

On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:

Hi,
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.


Try 6.1 stock kernel and see if that works. Then at least we know if we
introduced a regression.

Nobody knows (or cares) what NROOT is.

-ml




http://wklej.org/hash/e590382de31/

boot>
booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
[680614+82+489520+501323]=0xcc233c
entry point at 0x2000d4

[ using 1671996 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
 The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.2 (GENERIC) #163: Tue Oct  3 19:51:20 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1005654016 (959MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 02/14/07, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0H"
date 02/14/2007
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
UAR1(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0401" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
ddb>







http://wklej.org/hash/e590382de31/

# dmesg
OpenBSD 6.1-stable (NROOT) #12: Fri Oct 13 17:15:13 CEST 2017
 krz...@nroot.pl:/usr/src/sys/arch/i386/compile/NROOT
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1006993408 (960MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
date 05/14/2008
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1800
0xd2000/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
sisagp0 at pchb0
agp0 at sisagp0: aperture at 0xe800, size 0x400
ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 3 function 0 "SiS 5597/5598 USB" rev 0x0f: irq 4,
version 1.0, legacy support
ohci1 at pci0 dev 3 function 1 "SiS 5597/5598 USB" rev 0x0f: irq 3,
version 1.0, legacy support
ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: irq 7
ehci0: timed out waiting for BIOS
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "SiS EHCI root hub" rev
2.00/1.00 

Re: kernel panic i386

[Mike Larkin]

On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:
> Hi,
> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
> 

Try 6.1 stock kernel and see if that works. Then at least we know if we
introduced a regression.

Nobody knows (or cares) what NROOT is.

-ml

> 
> 
> http://wklej.org/hash/e590382de31/
> 
> boot>
> booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
> [680614+82+489520+501323]=0xcc233c
> entry point at 0x2000d4
> 
> [ using 1671996 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.2 (GENERIC) #163: Tue Oct  3 19:51:20 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
> cache) 1.01 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
> real mem  = 1039613952 (991MB)
> avail mem = 1005654016 (959MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 02/14/07, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
> 2.2 @ 0xf (31 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0H"
> date 02/14/2007
> bios0: FUJITSU SIEMENS FUTRO S400
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT
> acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
> UAR1(S5) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> "PNP0401" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1000
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
> ddb>
> 
> 
> 
> 
> 
> 
> 
> http://wklej.org/hash/e590382de31/
> 
> # dmesg
> OpenBSD 6.1-stable (NROOT) #12: Fri Oct 13 17:15:13 CEST 2017
> krz...@nroot.pl:/usr/src/sys/arch/i386/compile/NROOT
> cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
> cache) 1.01 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
> real mem  = 1039613952 (991MB)
> avail mem = 1006993408 (960MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
> 2.2 @ 0xf (31 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
> date 05/14/2008
> bios0: FUJITSU SIEMENS FUTRO S400
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT
> acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> "PNP0C0B" at acpi0 not configured
> bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1800
> 0xd2000/0x1000
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
> sisagp0 at pchb0
> agp0 at sisagp0: aperture at 0xe800, size 0x400
> ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
> pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
> channel 0 configured to compatibility, channel 1 configured to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciid

kernel panic i386

[Krzysztof Strzeszewski]

Hi,
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.



http://wklej.org/hash/e590382de31/

boot>
booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
[680614+82+489520+501323]=0xcc233c
entry point at 0x2000d4

[ using 1671996 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.2 (GENERIC) #163: Tue Oct  3 19:51:20 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1005654016 (959MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 02/14/07, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0H"
date 02/14/2007
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
UAR1(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0401" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
ddb>







http://wklej.org/hash/e590382de31/

# dmesg
OpenBSD 6.1-stable (NROOT) #12: Fri Oct 13 17:15:13 CEST 2017
krz...@nroot.pl:/usr/src/sys/arch/i386/compile/NROOT
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1006993408 (960MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
date 05/14/2008
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1800
0xd2000/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
sisagp0 at pchb0
agp0 at sisagp0: aperture at 0xe800, size 0x400
ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 3 function 0 "SiS 5597/5598 USB" rev 0x0f: irq 4,
version 1.0, legacy support
ohci1 at pci0 dev 3 function 1 "SiS 5597/5598 USB" rev 0x0f: irq 3,
version 1.0, legacy support
ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: irq 7
ehci0: timed out waiting for BIOS
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "SiS EHCI root hub" rev
2.00/1.00 addr 1
em0 at pci0 dev 7 function 0 "Intel 82546EB" rev 0x01: irq 10, address
00:11:0a:5b:69:e8
em1 at pci0 dev 7 function 1 "Intel 82546EB" rev 0x01: irq 11, address
00:11:0a:5b:69:e9
re0 at pci0 dev 9 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB
(0x1000), irq

Re: simple-mtpfs kernel panic

[Olivier Antoine]

Hi,

I tested this patch. From what I've seen, it works perfectly.
After suspend / resume, I did not notice any problem.

Thanks for the resolution of this bug.



On Tue, Oct 3, 2017 at 11:27 AM, Martin Pieuchot  wrote:
> On 01/10/17(Sun) 20:35, Olivier Antoine wrote:
>> Hi,
>>
>> Looks like this bug: 
>>
>> I can also reproduce this with:
>>
>> $ while true ; do adb shell ls / ; adb kill-server ; done
>>
>> The code which is triggered in /sys/dev/usb/ehci.c:
>>
>> ehci_device_clear_toggle(struct usbd_pipe *pipe)
>> {
>> struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
>>
>> #ifdef DIAGNOSTIC
>> if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 
>> 0)
>> panic("ehci_device_clear_toggle: queue active");
>> #endif
>> epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
>> }
>>
>> Don't know if it's hardware specific. But I can confirm that it hit me too.
>
> Bug reports without dmesg are useless, see sendbug(1).
>
> Anyway, here's a diff that should fix the problem.  However last I
> couldn't narrow down possible regressions.  So make sure everything
> works with it, including suspend/resume.
>
> Index: ehci.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ehci.c,v
> retrieving revision 1.200
> diff -u -p -r1.200 ehci.c
> --- ehci.c  15 May 2017 10:52:08 -  1.200
> +++ ehci.c  3 Oct 2017 09:24:08 -
> @@ -116,6 +116,7 @@ usbd_status ehci_open(struct usbd_pipe *
>  intehci_setaddr(struct usbd_device *, int);
>  void   ehci_poll(struct usbd_bus *);
>  void   ehci_softintr(void *);
> +intehci_start(struct ehci_softc *);
>  intehci_intr1(struct ehci_softc *);
>  void   ehci_check_intr(struct ehci_softc *, struct usbd_xfer *);
>  void   ehci_check_qh_intr(struct ehci_softc *, struct usbd_xfer *);
> @@ -188,12 +189,11 @@ int   ehci_alloc_sitd_chain(struct ehci_s
>  void   ehci_abort_isoc_xfer(struct usbd_xfer *xfer,
> usbd_status status);
>
> -usbd_statusehci_device_setintr(struct ehci_softc *, struct ehci_soft_qh 
> *,
> -   int ival);
> +struct ehci_soft_qh * ehci_intr_get_sqh(struct usbd_pipe *);
>
> -void   ehci_add_qh(struct ehci_soft_qh *, struct ehci_soft_qh *);
> -void   ehci_rem_qh(struct ehci_softc *, struct ehci_soft_qh *);
> -void   ehci_set_qh_qtd(struct ehci_soft_qh *, struct ehci_soft_qtd 
> *);
> +void   ehci_add_qh(struct usbd_pipe *, struct ehci_soft_qh *,
> +   struct ehci_soft_qtd *);
> +void   ehci_rem_qh(struct ehci_softc *, struct usbd_pipe *);
>  void   ehci_sync_hc(struct ehci_softc *);
>
>  void   ehci_close_pipe(struct usbd_pipe *);
> @@ -295,7 +295,7 @@ ehci_reverse_bits(u_int8_t c, int nbits)
>  usbd_status
>  ehci_init(struct ehci_softc *sc)
>  {
> -   u_int32_t sparams, cparams, hcr;
> +   uint32_t sparams;
> u_int i, j;
> usbd_status err;
> struct ehci_soft_qh *sqh;
> @@ -316,20 +316,8 @@ ehci_init(struct ehci_softc *sc)
> sparams = EREAD4(sc, EHCI_HCSPARAMS);
> DPRINTF(("ehci_init: sparams=0x%x\n", sparams));
> sc->sc_noport = EHCI_HCS_N_PORTS(sparams);
> -   cparams = EREAD4(sc, EHCI_HCCPARAMS);
> -   DPRINTF(("ehci_init: cparams=0x%x\n", cparams));
> -
> -   /* MUST clear segment register if 64 bit capable. */
> -   if (EHCI_HCC_64BIT(cparams))
> -   EWRITE4(sc, EHCI_CTRLDSSEGMENT, 0);
> -
> sc->sc_bus.usbrev = USBREV_2_0;
>
> -   DPRINTF(("%s: resetting\n", sc->sc_bus.bdev.dv_xname));
> -   err = ehci_reset(sc);
> -   if (err)
> -   return (err);
> -
> if (ehcixfer == NULL) {
> ehcixfer = malloc(sizeof(struct pool), M_DEVBUF, M_NOWAIT);
> if (ehcixfer == NULL) {
> @@ -365,8 +353,6 @@ ehci_init(struct ehci_softc *sc)
> for (i = 0; i < sc->sc_flsize; i++)
> sc->sc_flist[i] = htole32(EHCI_LINK_TERMINATE);
>
> -   EOWRITE4(sc, EHCI_PERIODICLISTBASE, DMAADDR(>sc_fldma, 0));
> -
> sc->sc_softitds = mallocarray(sc->sc_flsize,
> sizeof(struct ehci_soft_itd *), M_USB, M_NOWAIT | M_ZERO);
> if (sc->sc_softitds == NULL) {
> @@ -412,7 +398,6 @@ ehci_init(struct ehci_softc *sc)
> sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
> sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
> sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
> -   sqh->sqtd = NULL;
> usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
> BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
> }
> @@ -443,18 +428,47 @@ ehci_init(struct ehci_softc *sc)
> sqh->qh.qh_qtd.qtd_next 

Re: simple-mtpfs kernel panic

[Martin Pieuchot]

On 01/10/17(Sun) 20:35, Olivier Antoine wrote:
> Hi,
> 
> Looks like this bug: 
> 
> I can also reproduce this with:
> 
> $ while true ; do adb shell ls / ; adb kill-server ; done
> 
> The code which is triggered in /sys/dev/usb/ehci.c:
> 
> ehci_device_clear_toggle(struct usbd_pipe *pipe)
> {
> struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
> 
> #ifdef DIAGNOSTIC
> if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 
> 0)
> panic("ehci_device_clear_toggle: queue active");
> #endif
> epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
> }
> 
> Don't know if it's hardware specific. But I can confirm that it hit me too.

Bug reports without dmesg are useless, see sendbug(1).

Anyway, here's a diff that should fix the problem.  However last I
couldn't narrow down possible regressions.  So make sure everything
works with it, including suspend/resume.

Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.200
diff -u -p -r1.200 ehci.c
--- ehci.c  15 May 2017 10:52:08 -  1.200
+++ ehci.c  3 Oct 2017 09:24:08 -
@@ -116,6 +116,7 @@ usbd_status ehci_open(struct usbd_pipe *
 intehci_setaddr(struct usbd_device *, int);
 void   ehci_poll(struct usbd_bus *);
 void   ehci_softintr(void *);
+intehci_start(struct ehci_softc *);
 intehci_intr1(struct ehci_softc *);
 void   ehci_check_intr(struct ehci_softc *, struct usbd_xfer *);
 void   ehci_check_qh_intr(struct ehci_softc *, struct usbd_xfer *);
@@ -188,12 +189,11 @@ int   ehci_alloc_sitd_chain(struct ehci_s
 void   ehci_abort_isoc_xfer(struct usbd_xfer *xfer,
usbd_status status);
 
-usbd_statusehci_device_setintr(struct ehci_softc *, struct ehci_soft_qh *,
-   int ival);
+struct ehci_soft_qh * ehci_intr_get_sqh(struct usbd_pipe *);
 
-void   ehci_add_qh(struct ehci_soft_qh *, struct ehci_soft_qh *);
-void   ehci_rem_qh(struct ehci_softc *, struct ehci_soft_qh *);
-void   ehci_set_qh_qtd(struct ehci_soft_qh *, struct ehci_soft_qtd *);
+void   ehci_add_qh(struct usbd_pipe *, struct ehci_soft_qh *,
+   struct ehci_soft_qtd *);
+void   ehci_rem_qh(struct ehci_softc *, struct usbd_pipe *);
 void   ehci_sync_hc(struct ehci_softc *);
 
 void   ehci_close_pipe(struct usbd_pipe *);
@@ -295,7 +295,7 @@ ehci_reverse_bits(u_int8_t c, int nbits)
 usbd_status
 ehci_init(struct ehci_softc *sc)
 {
-   u_int32_t sparams, cparams, hcr;
+   uint32_t sparams;
u_int i, j;
usbd_status err;
struct ehci_soft_qh *sqh;
@@ -316,20 +316,8 @@ ehci_init(struct ehci_softc *sc)
sparams = EREAD4(sc, EHCI_HCSPARAMS);
DPRINTF(("ehci_init: sparams=0x%x\n", sparams));
sc->sc_noport = EHCI_HCS_N_PORTS(sparams);
-   cparams = EREAD4(sc, EHCI_HCCPARAMS);
-   DPRINTF(("ehci_init: cparams=0x%x\n", cparams));
-
-   /* MUST clear segment register if 64 bit capable. */
-   if (EHCI_HCC_64BIT(cparams))
-   EWRITE4(sc, EHCI_CTRLDSSEGMENT, 0);
-
sc->sc_bus.usbrev = USBREV_2_0;
 
-   DPRINTF(("%s: resetting\n", sc->sc_bus.bdev.dv_xname));
-   err = ehci_reset(sc);
-   if (err)
-   return (err);
-
if (ehcixfer == NULL) {
ehcixfer = malloc(sizeof(struct pool), M_DEVBUF, M_NOWAIT);
if (ehcixfer == NULL) {
@@ -365,8 +353,6 @@ ehci_init(struct ehci_softc *sc)
for (i = 0; i < sc->sc_flsize; i++)
sc->sc_flist[i] = htole32(EHCI_LINK_TERMINATE);
 
-   EOWRITE4(sc, EHCI_PERIODICLISTBASE, DMAADDR(>sc_fldma, 0));
-
sc->sc_softitds = mallocarray(sc->sc_flsize,
sizeof(struct ehci_soft_itd *), M_USB, M_NOWAIT | M_ZERO);
if (sc->sc_softitds == NULL) {
@@ -412,7 +398,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
}
@@ -443,18 +428,47 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(>dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
 
/* Point to async list */
sc->sc_async_head = sqh;
-   EOWRITE4(sc, EHCI_ASYNCLISTADDR, sqh->physaddr | 

Re: simple-mtpfs kernel panic

[Olivier Antoine]

Hi,

Looks like this bug: 

I can also reproduce this with:

$ while true ; do adb shell ls / ; adb kill-server ; done

The code which is triggered in /sys/dev/usb/ehci.c:

ehci_device_clear_toggle(struct usbd_pipe *pipe)
{
struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;

#ifdef DIAGNOSTIC
if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 0)
panic("ehci_device_clear_toggle: queue active");
#endif
epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
}

Don't know if it's hardware specific. But I can confirm that it hit me too.

-- 
Olivier A.

simple-mtpfs kernel panic

[Christian Schulte]

Hi misc@,

during transferring some files from my laptop to my Android mobile
mounted using simple-mtpfs, the machine rebooted and /var/crash now
contains the following files:

$ ls -h /var/crash/
bounds  bsd.0   bsd.0.core  minfree

I read crash(8) but cannot get any meaningful information from gdb for
me. If someone is interested, I can send those files (amd64). It just
happened once and I cannot reproduce it.

$ dmesg -M /var/crash/bsd.0.core -N /var/crash/bsd.0
ugen2 at uhub0 port 2 "LGE LG-E610v" rev 2.00/2.33 addr 2
fusefs: libfuse vnode reclaim failed
panic: ehci_device_clear_toggle: queue active
Starting stack trace...
panic() at panic+0x10b
ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
ugen_do_write() at ugen_do_write+0x175
ugenwrite() at ugenwrite+0x48
spec_write() at spec_write+0xbb
VOP_WRITE() at VOP_WRITE+0x3f
vn_write() at vn_write+0x98
dofilewritev() at dofilewritev+0x205
sys_write() at sys_write+0x89
syscall() at syscall+0x2b8
--- syscall (number 4) ---
end of kernel
end trace frame: 0x1, count: 246
0x5c7f4107c9a:
End of stack trace.
syncing disks... 4 done

Regards,
-- 
Christian

Re: 6.1-stable: kernel panic on pf_state_key_unref()

[Mathieu BLANC]

Le 07/09/2017 à 05:59, Maxim Bourmistrov a écrit :

Hey,
Got kernel panic on 6.1-stable during ’rcctl restart relayd’.

Sorry for PNG below.




Hi,

It has been fixed with this diff :
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.1034=1.1035

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, May 02, 2017 at 05:03:20PM +, Stuart Henderson wrote:
> Probably the best thing to do at this point is to write a mail to bugs@:
> 
> 1. describe what the machine is doing in detail. carp? ipsec? pfsync?
> what sort of relays? include config (sanitized if necessary, but do that
> consistently).
> 
> 2. copy in the panic message and stack trace as text (re-type it,
> don't attach a picture or send a link to a picture).
> 
> 3. make it a self-contained report with description etc all in the one
> message, don't rely on people having message history.
> 
> 4. include dmesg.

Hi Stuart, 

Thx for your answer !
I didn't have the time to work on this since early may.
But from time to time, I check the commit on pf.c and I saw this one which
seemed to perfectly match my bug :
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c?rev=1.1035=text/x-cvsweb-markup

I tried the diff, and it seems to be OK ! I can't trigger the bug right now (it
was 100% before).

So, thx you again, and special thx to bluhm@ who made the patch ! 

-- 
Mathieu

kernel panic: ehci_device_clear_toggle

[Nicolas Schmidt]

Hi,

I just installed OpenBSD 6.1 and set up a CUPS server with a usb printer, and 
I'm experiencing kernel panics that seem usb related.
These kernel panics actually occured also on the old version of OpenBSD I 
upgraded from, but only very rarely (once every few months a most). Now I've 
had three panics in the course of a few hours. The irony is that one of the 
reasons for upgradings was this exact problem; I assumed it would have been 
fixed, as it was mentioned on this list already.

I would like to file a bug report, but I can't gather all the infos asked for 
https://www.openbsd.org/ddb.html, as the keyboard stops working after the 
kernel panic (probably because it's a usb keyboard). So, here's the output I 
can give you:

# panic: ehci_device_clear_toggle: queue active
Stopped at  Debugger+0x7:   leave
TID PID UID PRFLAGS PFLAGS  CPU COMMAND
*359035 78367   541 0x1002  0x8 1   usb
216484  46276   0   0x14000 0x200   0   reaper
Debugger(d0a08f55,f54ee848,d09d62e0,f54ee848,0) at Debugger+0x7
panic(d09d62e0,dbaed460,f54ee88c,d08a0895,0) at panic+0x71
ehci_device_clear_toggle(d5d8ff00,d5d8ff00,d5a02800,0,2) at 
ehci_device_clear_toggle+0x29
usbd_clear_endpoint_stall(d5d8ff00,d5d8ff00,0,f54ee8dc,400) at 
usbd_clear_endpoint_stall+0x20
ugen_do_write(d5aa,1,f54eee8c,1,f54eed10) at ugen_do_write+0x2a8
ugenwrite(3f01,f54eee8c,1,d0508d09,db91169c) at ugenwrite+0x4f
spec_write(f54eedb8,db7b2aa4,f54eee74,d03cd5e9,d0bf6ae0) at spec_write+0xa7
VOP_WRITE(dba0fccc,f54eee8c,1,dbaf2c00,17a8840) at VOP_WRITE+0x42
vn_write(db91169c,db91116b4,f54eee8c,dbaf2c00,d0bf6ae0) at vn_write+0x8a
dofilewritev(db7b2aa4,8,db91169c,f54eeef4,1) at dofilewritev+0x1c6
sys_write(db7b2aa4,f54eef5c,f54eef7c,0,200286) at sys_write+0x8f
syscall() at syscall+0x250
--- syscall (number -813756072) ---
0x6:



One piece of context: the uid 541 is the user _cups, under which cupsd runs.

Best,
Nicolas

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Stuart Henderson]

On 2017-05-02, Mathieu BLANC <mathieu.bl...@smile.fr> wrote:
> On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:
>> It also kernel panics with just this pf rules :
>> # cat pf_minimal.conf 
>> set limit { states 10 }  
>> set skip on lo   
>> anchor "relayd/*"
>> pass 
>> 
>
> I upgraded the system to 6.1 release last week, the kernel panic is still here
> (with the same logs).

Probably the best thing to do at this point is to write a mail to bugs@:

1. describe what the machine is doing in detail. carp? ipsec? pfsync?
what sort of relays? include config (sanitized if necessary, but do that
consistently).

2. copy in the panic message and stack trace as text (re-type it,
don't attach a picture or send a link to a picture).

3. make it a self-contained report with description etc all in the one
message, don't rely on people having message history.

4. include dmesg.

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Tue, May 02, 2017 at 03:44:43PM +0200, Andre Ruppert wrote:
> Hi,
> 
> Im running 6.0 amd64 on a pair of R210 with relayd, but these are R210 (II).
> 
> No kernel panics at all, and these systems are working in a live
> environment...
> 
> Regards
> Andre

Hi,

Yes, i have also several OpenBSD on R210 + 6.0 (or 6.1) + relayd and it works
like a charm. 

The only problem appeared when an admin did a REJECT (iptables) on one on the
host checked by relayd with check tcp (i tried to put all the details i could
in the previous mails).

The next step is to try with current (until now i've waited for the 6.1 release
which was very close to be released).

-- 
Mathieu

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Andre Ruppert]

Hi,

Im running 6.0 amd64 on a pair of R210 with relayd, but these are R210 (II).

No kernel panics at all, and these systems are working in a live 
environment...


Regards
Andre



Am 02.05.17 um 15:03 schrieb Mathieu BLANC:

On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:

It also kernel panics with just this pf rules :
# cat pf_minimal.conf
set limit { states 10 }
set skip on lo
anchor "relayd/*"
pass



I upgraded the system to 6.1 release last week, the kernel panic is still here
(with the same logs).





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)

[Mathieu BLANC]

On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:
> It also kernel panics with just this pf rules :
> # cat pf_minimal.conf 
> set limit { states 10 }  
> set skip on lo   
> anchor "relayd/*"
> pass 
> 

I upgraded the system to 6.1 release last week, the kernel panic is still here
(with the same logs).

-- 
Mathieu

Re: kernel panic question

[Alexei Malinin]

On 04/04/17 20:40, Stuart Henderson wrote:
>>> I have a case of OpenBSD-5.9 (i386) kernel panic.
> Upgrade.

I suspect that this kernel panic could be caused by hardware problems so
upgrade will not be a cure.
I sent the problem report to b...@openbsd.org
(http://marc.info/?l=openbsd-bugs=149130924005169=2).
Can anybody say about possible causes of this panic?


--
Alexei Malinin

Re: kernel panic question

[Stuart Henderson]

It looks more like a bug than a hw fault. Upgrading (preferably to a 
-current snapshot) means we will know whether the problem still exists or 
whether it has been fixed already and gives an easier base for anyone 
trying to track it down if it's still there.


--
 Sent from a phone, apologies for poor formatting.



On 4 April 2017 19:16:13 Alexei Malinin <alexei.mali...@mail.ru> wrote:


On 04/04/17 20:40, Stuart Henderson wrote:

I have a case of OpenBSD-5.9 (i386) kernel panic.

Upgrade.


I suspect that this kernel panic could be caused by hardware problems so
upgrade will not be a cure.
I sent the problem report to b...@openbsd.org
(http://marc.info/?l=openbsd-bugs=149130924005169=2).
Can anybody say about possible causes of this panic?


--
Alexei Malinin

Re: kernel panic question

[Stuart Henderson]

>> I have a case of OpenBSD-5.9 (i386) kernel panic.

Upgrade.

Re: Kernel panic during boot on Dell Inspiron 15-5558

[Stuart Henderson]

On 2017-04-02, Niko Pavlinek  wrote:
> On 2. 04. 2017 14:08, Stuart Henderson wrote:
>>
>> Please try a -current snapshot and report back. If you get it now (before
>> the kernel version moves to 6.1-current) you'll be able to safely update
>> to the proper 6.1 release when it's out.
>>
>> ACPI is really required for modern PC hardware, it is tied up with many
>> aspects of the system including cooling, I would not run a machine for
>> longer than a quick test without it.
>>
>
> Hello,
>
> No luck.  I've tried the -current snapshot released on Friday
> (31.03.2017) and the one released on Saturday (01.04.2017), but
> both have yielded the same error.
>
> If I can provide any more info I would be happy to do so.
>
>

In that case, the best option is probably to boot -current with acpi disabled
and run "sendbug" as root. It's probably simplest to use "sendbug -P >
/tmp/sendbug.txt" and copy that to another machine, then edit (please include
the information from your previous report) and send it to b...@openbsd.org.
This will include PCI tables and a base64-encoded copy of the ACPI tables.

Re: kernel panic question

[Edgar Pettijohn]

Is it a soekris? If so http://wiki.soekris.info/Installing_OpenBSD.

If not https://www.openbsd.org/report.html

Sent from my iPhone

> On Apr 3, 2017, at 8:34 AM, Alexei Malinin <alexei.mali...@mail.ru> wrote:
> 
> Hello.
> 
> I have a case of OpenBSD-5.9 (i386) kernel panic. I'd like to be pointed
> out to possible causes of the problem. Please tell me what info should I
> include to send useful kernel panic report.
> 
> Now I have this:
> 
> uvm_fault(0xd0ba6660, 0xdaf25000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  uvm_km_doputpage+0x12:  movl0(%ebx),%edi
> ddb{0}>
> 
> 
> --
> Alexei Malinin

kernel panic question

[Alexei Malinin]

Hello.

I have a case of OpenBSD-5.9 (i386) kernel panic. I'd like to be pointed
out to possible causes of the problem. Please tell me what info should I
include to send useful kernel panic report.

Now I have this:

uvm_fault(0xd0ba6660, 0xdaf25000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  uvm_km_doputpage+0x12:  movl0(%ebx),%edi
ddb{0}>


--
Alexei Malinin

Re: Kernel panic during boot on Dell Inspiron 15-5558

[Niko Pavlinek]

On 2. 04. 2017 14:08, Stuart Henderson wrote:
>
> Please try a -current snapshot and report back. If you get it now (before
> the kernel version moves to 6.1-current) you'll be able to safely update
> to the proper 6.1 release when it's out.
>
> ACPI is really required for modern PC hardware, it is tied up with many
> aspects of the system including cooling, I would not run a machine for
> longer than a quick test without it.
>

Hello,

No luck.  I've tried the -current snapshot released on Friday
(31.03.2017) and the one released on Saturday (01.04.2017), but
both have yielded the same error.

If I can provide any more info I would be happy to do so.