Re: Suspend does not work on Dell latitute d380

[Mike Larkin]

On Wed, Feb 06, 2013 at 09:34:24PM +0100, carsten.ku...@arcor.de wrote:
 Synopsis:  Dell Latitute D380: Resume from zzz: Display stays off
 Category:  Suspend
 Environment:
 System  : OpenBSD 5.2
 Details : OpenBSD 5.2 (GENERIC.MP) #368: Wed Aug  1 10:04:49 MDT 
 2012
  
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
 Architecture: OpenBSD.amd64
 Machine : amd64
 Description:
 Display stays off on resume from suspend. The wlan starts working so 
 i can log in from
 a other machine.
 How-To-Repeat:
 - login as root
 - # /etc/rc.d/xdm stop
 - # zzz
 - press power button
 - system starts correctly but display stays off (unpowered)
 
 machine is a dell latitute d380 laptop
 
 Fix:
   how to correct or work around the problem, if known (multiple lines)

vga1 at pci1 dev 0 function 0 vendor NVIDIA, unknown product 0x042b rev 0xa1

Until NVIDIA tells us how to resume their chips, you won't have working video
on resume.

-ml

Re: Noppoo choc MX blue bug on installation

[Mike Larkin]

On Tue, Jul 16, 2013 at 01:37:59PM -0300, Marcos Taranta wrote:
 Hi there.
 
 I'm using OpenBSD on my notebook without any problems, but when I tried to
 install it on my desktop yesterday, even after managing to configure the
 keyboard layout option with US, the keyboard is all weird, like for typing
 US, I had to press the keys 3 and y to get u and s, and some letters
 doesn't even have an key to press, like the letter b.
 I think the problem is somewhat related to my keyboard being a noppoo choc
 usb mechanical mx blue keyboard.
 

I fixed a variety of these types of keyboards about a year ago. What version
of OpenBSD are you using?

PS - your bug report sucks. No dmesg, no help.

Re: Display stays off after waking from suspend-to-ram (zzz)

[Mike Larkin]

: isadma0 at isa0
 Oct  9 21:08:50 tietsika /bsd: pckbc0 at isa0 port 0x60/5
 Oct  9 21:08:50 tietsika /bsd: pckbd0 at pckbc0 (kbd slot)
 Oct  9 21:08:50 tietsika /bsd: pckbc0: using irq 1 for kbd slot
 Oct  9 21:08:50 tietsika /bsd: wskbd0 at pckbd0: console keyboard, using
 wsdisplay0
 Oct  9 21:08:50 tietsika /bsd: pms0 at pckbc0 (aux slot)
 Oct  9 21:08:50 tietsika /bsd: pckbc0: using irq 12 for aux slot
 Oct  9 21:08:50 tietsika /bsd: wsmouse0 at pms0 mux 0
 Oct  9 21:08:50 tietsika /bsd: wsmouse1 at pms0 mux 0
 Oct  9 21:08:50 tietsika /bsd: pms0: Synaptics touchpad, firmware 7.2
 Oct  9 21:08:50 tietsika /bsd: pcppi0 at isa0 port 0x61
 Oct  9 21:08:50 tietsika /bsd: spkr0 at pcppi0
 Oct  9 21:08:50 tietsika /bsd: aps0 at isa0 port 0x1600/31
 Oct  9 21:08:50 tietsika /bsd: pci6 at mainbus0 bus 255
 Oct  9 21:08:50 tietsika /bsd: pchb1 at pci6 dev 0 function 0 Intel
 QuickPath rev 0x02
 Oct  9 21:08:50 tietsika /bsd: pchb2 at pci6 dev 0 function 1 Intel
 QuickPath rev 0x02
 Oct  9 21:08:50 tietsika /bsd: pchb3 at pci6 dev 2 function 0 Intel QPI Link
 rev 0x02
 Oct  9 21:08:50 tietsika /bsd: pchb4 at pci6 dev 2 function 1 Intel QPI
 Physical rev 0x02
 Oct  9 21:08:50 tietsika /bsd: pchb5 at pci6 dev 2 function 2 Intel Reserved
 rev 0x02
 Oct  9 21:08:50 tietsika /bsd: pchb6 at pci6 dev 2 function 3 Intel Reserved
 rev 0x02
 Oct  9 21:08:50 tietsika /bsd: mtrr: Pentium Pro MTRR support, 8 var ranges,
 88 fixed ranges
 Oct  9 21:08:50 tietsika /bsd: uhub2 at uhub0 port 1 Intel Rate Matching Hub
 rev 2.00/0.00 addr 2
 Oct  9 21:08:50 tietsika /bsd: umass0 at uhub2 port 2 configuration 1
 interface 0 Generic USB Storage rev 2.00/2.07 addr 3
 Oct  9 21:08:50 tietsika /bsd: umass0: using SCSI over Bulk-Only
 Oct  9 21:08:50 tietsika /bsd: scsibus2 at umass0: 2 targets, initiator 0
 Oct  9 21:08:50 tietsika /bsd: sd1 at scsibus2 targ 1 lun 0: Generic, STORAGE
 DEVICE, 0207 SCSI0 0/direct removable serial.05e307270207
 Oct  9 21:08:50 tietsika /bsd: sd1: 3768MB, 512 bytes/sector, 7716864 sectors
 Oct  9 21:08:50 tietsika /bsd: uhub3 at uhub1 port 1 Intel Rate Matching Hub
 rev 2.00/0.00 addr 2
 Oct  9 21:08:50 tietsika /bsd: uhub4 at uhub3 port 1 Genesys Logic USB2.0
 Hub rev 2.00/9.01 addr 3
 Oct  9 21:08:50 tietsika /bsd: uhidev0 at uhub4 port 1 configuration 1
 interface 0 Dell Dell QuietKey Keyboard rev 1.10/1.30 addr 4
 Oct  9 21:08:50 tietsika /bsd: uhidev0: iclass 3/1
 Oct  9 21:08:50 tietsika /bsd: ukbd0 at uhidev0: 8 variable keys, 6 key codes
 Oct  9 21:08:50 tietsika /bsd: wskbd1 at ukbd0 mux 1
 Oct  9 21:08:50 tietsika /bsd: wskbd1: connecting to wsdisplay0
 Oct  9 21:08:50 tietsika /bsd: uhidev1 at uhub4 port 3 configuration 1
 interface 0 Logitech USB-PS/2 Optical Mouse rev 2.00/21.00 addr 5
 Oct  9 21:08:50 tietsika /bsd: uhidev1: iclass 3/1
 Oct  9 21:08:50 tietsika /bsd: ums0 at uhidev1: 8 buttons, Z dir
 Oct  9 21:08:50 tietsika /bsd: wsmouse2 at ums0 mux 0
 Oct  9 21:08:50 tietsika /bsd: vscsi0 at root
 Oct  9 21:08:50 tietsika /bsd: scsibus3 at vscsi0: 256 targets
 Oct  9 21:08:50 tietsika /bsd: softraid0 at root
 Oct  9 21:08:50 tietsika /bsd: scsibus4 at softraid0: 256 targets
 Oct  9 21:08:50 tietsika /bsd: root on sd0a (1bd60f2cfbc52b38.a) swap on sd0b
 dump on sd0b
 Oct  9 21:08:50 tietsika savecore: no core dump
 Oct  9 21:10:04 tietsika apmd: battery status: high. external power status:
 connected. estimated battery life 84%
 Oct  9 21:14:46 tietsika syslogd: start
 
 
 On Wed, Oct 09, 2013 at 11:04:03AM -0700, Mike Larkin wrote:
  On Wed, Oct 09, 2013 at 06:56:22PM +0300, Ilmari Jaaranen wrote:
   I tried booting without inteldrm but it didn't fix or alter the problem.
  
 
  dmesg?
 
 
   -Ilmari
  
Try running once without inteldrm (boot -c, disable inteldrm) to see if
those
recent changes are causing this. You'll get the old style text
 console
and won't be able to run X, but it should be simple enough to run a
 quick
zzz test.
   
-ml
   
   
On Wed, Oct 09, 2013 at 06:18:21PM +0300, Ilmari Jaaranen wrote:
Waking from suspend-to-ram, light and deep sleep modes (zzz -S, zzz
 -z,
shortcut: fn+F4), does not set the display on.
   
The power button changes from blinking state to stable and the fans
start
spinning but the display stays off.
   
When I try to type blindly into the logged in root terminal (ctrl +
 alt
+
F2) reboot and shutdown commands, the computer doesn't respond.
   
This is probably not a Xorg issue, because the problem occurs just
 after
boot without Xorg running. It also occurs with Xorg running.
   
I haven't run into this problem with the previous version of OpenBSD
(5.3).
   
System logs are offered as attachments.
   
Setup:
   
OpenBSD 5.4 GENERIC.MP#63 amd64
cvs updated /usr/ports
   
Hardware:
   
Lenovo Thinkpad t410i
Intel HD Graphics.
   
Sequence of the specific steps taken:
   
A)
1. boot
2. login as wheel user
3. su
4

Re: No resume after suspend anymore

[Mike Larkin]

On Thu, Apr 24, 2014 at 11:00:42PM +0200, Martin Pieuchot wrote:
 On 24/04/14(Thu) 21:47, Nils R wrote:
  Hi bugs@,
  
  my machine stopped resuming from suspend.  I was following -current until 
  the time when 5.5 was tagged, and back then, my machine always resumed 
  without any problems.  Now, i updated to the latest snapshot from 22.4..  
  With that, the machine goes to sleep, but does not quite wake up -- the fan 
  starts, and i can open/close the cd drive, but the screen stays black and 
  there is no network/ssh.  It doesn't matter whether i suspend from tty or 
  from X.
  
  Any thoughts?
 
 You can try reverting the last commit to /sys/dev/usb/usb.c and see if
 it is the cause of your problem.  If that's the case, could you try
 suspending/resuming without any usb device attached and if that helps
 try to find which device breaks your resume.
 

I'd try what mpi@ says above before trying bisecting diffs like I 
suggested in that private mail I sent a few minutes ago.

-ml

  
  Best,
  Nils
  
  dmesg:
  OpenBSD 5.5-current (GENERIC.MP) #80: Tue Apr 22 08:36:02 MDT 2014
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  real mem = 3738107904 (3564MB)
  avail mem = 3629875200 (3461MB)
  mpath0 at root
  scsibus0 at mpath0: 256 targets
  mainbus0 at root
  bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (61 entries)
  bios0: vendor Award Software International, Inc. version F4 date 
  07/28/2010
  bios0: Gigabyte Technology Co., Ltd. GA-880GMA-UD2H
  acpi0 at bios0: rev 0
  acpi0: sleep states S0 S3 S4 S5
  acpi0: tables DSDT FACP SSDT HPET MCFG MATS APIC
  acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
  USB6(S3) SBAZ(S4) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) P2P_(S5) PCE2(S4) 
  PCE3(S4) PCE4(S4) [...]
  acpitimer0 at acpi0: 3579545 Hz, 32 bits
  acpihpet0 at acpi0: 14318180 Hz
  acpimcfg0 at acpi0 addr 0xe000, bus 0-255
  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
  cpu0 at mainbus0: apid 0 (boot processor)
  cpu0: AMD Athlon(tm) II X2 240e Processor, 2813.25 MHz
  cpu0: 
  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
  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, 16 4MB entries fully 
  associative
  cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully 
  associative
  cpu0: AMD erratum 721 detected and fixed
  cpu0: smt 0, core 0, package 0
  mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
  cpu0: apic clock running at 200MHz
  cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
  cpu1 at mainbus0: apid 1 (application processor)
  cpu1: AMD Athlon(tm) II X2 240e Processor, 2812.92 MHz
  cpu1: 
  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
  cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 
  64b/line 16-way L2 cache
  cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully 
  associative
  cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully 
  associative
  cpu1: AMD erratum 721 detected and fixed
  cpu1: smt 0, core 1, package 0
  ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
  ioapic0: misconfigured as apic 0, remapped to apid 2
  acpiprt0 at acpi0: bus 0 (PCI0)
  acpiprt1 at acpi0: bus 5 (PEX0)
  acpiprt2 at acpi0: bus 6 (PEX1)
  acpiprt3 at acpi0: bus -1 (PEX2)
  acpiprt4 at acpi0: bus -1 (PEX3)
  acpiprt5 at acpi0: bus 4 (P2P_)
  acpiprt6 at acpi0: bus -1 (PCE2)
  acpiprt7 at acpi0: bus -1 (PCE3)
  acpiprt8 at acpi0: bus -1 (PCE4)
  acpiprt9 at acpi0: bus -1 (PCE5)
  acpiprt10 at acpi0: bus -1 (PCE6)
  acpiprt11 at acpi0: bus -1 (PCE7)
  acpiprt12 at acpi0: bus 2 (PCE9)
  acpiprt13 at acpi0: bus 3 (PCEA)
  acpiprt14 at acpi0: bus -1 (PCEB)
  acpiprt15 at acpi0: bus -1 (PCEC)
  acpiprt16 at acpi0: bus 1 (AGP_)
  acpicpu0 at acpi0: PSS
  acpicpu1 at acpi0: PSS
  acpibtn0 at acpi0: PWRB
  cpu0: 2813 MHz: speeds: 2800 2100 1600 800 MHz
  pci0 at mainbus0 bus 0
  0:0:0: mem address conflict 0xe000/0x2000
  pchb0 at pci0 dev 0 function 0 AMD RS880 Host rev 0x00
  ppb0 at pci0 dev 1 function 0 AMD RS780 PCIE rev 0x00
  pci1 at ppb0 bus 1
  radeondrm0 at pci1 dev 5 function 0 ATI Radeon HD 4250 rev 0x00
  drm0 at radeondrm0
  radeondrm0: apic 2 int 18
  azalia0 at pci1 dev 5 function 1 ATI Radeon HD 4200 HD Audio rev 0x00: msi
  azalia0: no supported codecs
  ppb1 at pci0 dev 9 function 0 AMD RS780 PCIE rev 0x00: msi
  pci2 at ppb1 bus 2
  NEC xHCI rev 0x03 at pci2 dev 0 function 0 not configured
  ppb2 at pci0 dev 10 function 0 AMD RS780 PCIE rev 0x00: msi
  pci3 at ppb2 

Re: Olivetti olibook S1350 snap20140820_i386

[Mike Larkin]

Where's the panic string and trace?


On Thu, Aug 21, 2014 at 06:40:50PM +0400, Wesley MOUEDINE ASSABY wrote:
 From root@snap56.20140820.i386 Thu Aug 21 22:32:55 2014
 Return-Path: root@snap56.20140820.i386
 Delivered-To: root@snap56.20140820.i386
 Received: from localhost (0@localhost [local]);
 by localhost (OpenSMTPD) with ESMTPA id 5a33a947;
 Thu, 21 Aug 2014 22:32:55 +0400 (RET)
 Date: Thu, 21 Aug 2014 22:32:55 +0400 (RET)
 Message-Id: 8156984609788695451.enqueue@snap56.20140820.i386
 To: bugs@openbsd.org
 Subject:
 From: root@snap56.20140820.i386
 Cc: root@snap56.20140820.i386
 Reply-To: root
 Status: R
 
 Synopsis:  kernel panic using the snapshot 20140820 i386 on a
 Olivetti Olibook s1350 laptop
 Category:  acpi
 Environment:
 System  : OpenBSD 5.6
 Details : OpenBSD 5.6-current (GENERIC.MP) #303: Tue Aug 19
 23:30:44 MDT 2014
  dera...@i386.openbsd.org:
 /usr/src/sys/arch/i386/compile/GENERIC.MP
 
 Architecture: OpenBSD.i386
 Machine : i386
 Description:
 start install with acpi support hang
 How-To-Repeat:
 just start the install or the os with acpi support
 Fix:
 disable acpi using UKC
 
 
 dmesg:
 OpenBSD 5.6-current (GENERIC.MP) #303: Tue Aug 19 23:30:44 MDT 2014
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 cpu0: Intel(R) Core(TM) i3 CPU U 330 @ 1.20GHz (GenuineIntel 686-class)
 1.20 GHz
 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
 real mem  = 3009986560 (2870MB)
 avail mem = 2948382720 (2811MB)
 User Kernel Config
 UKC disqb\^H \^H\^H \^Hable acpi
 491 acpi0 disabled
 UKC quit
 Continuing...
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 11/27/09, SMBIOS rev. 2.6 @
 0xb3594018 (108 entries)
 bios0: vendor American Megatrends Inc. version Spring Peak date 07/30/2010
 acpi at bios0 function 0x0 not configured
 mpbios0 at bios0: Intel MP Specification 1.4
 cpu0 at mainbus0: apid 0 (boot processor)
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 133MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
 cpu1 at mainbus0: apid 4 (application processor)
 cpu1: Intel(R) Core(TM) i3 CPU U 330 @ 1.20GHz (GenuineIntel 686-class)
 1.20 GHz
 cpu1:
 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,LAHF,PERF,ITSC
 mpbios0: bus 0 is type PCI
 mpbios0: bus 1 is type PCI
 mpbios0: bus 2 is type PCI
 mpbios0: bus 3 is type PCI
 mpbios0: bus 4 is type ISA
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
 pcibios at bios0 function 0x1a not configured
 bios0: ROM list: 0xc/0xf400! 0xcf800/0x1000
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x18
 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x18
 intagp0 at vga1
 agp0 at intagp0: aperture at 0xc000, size 0x1000
 inteldrm0 at vga1
 drm0 at inteldrm0
 inteldrm0: 1366x768
 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
 wsdisplay0: screen 1-5 added (std, vt100 emulation)
 Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured
 ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 0 int 16
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x06: msi
 azalia0: codecs: Realtek ALC269, Intel/0x2804, using Realtek ALC269
 audio0 at azalia0
 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x06: apic 0 int 17
 pci1 at ppb0 bus 1
 iwn0 at pci1 dev 0 function 0 Intel Centrino Wireless-N 2230 rev 0xc4:
 msi, MIMO 2T2R, BGN, address 68:17:29:9e:ba:42
 ppb1 at pci0 dev 28 function 4 Intel 3400 PCIE rev 0x06: apic 0 int 17
 pci2 at ppb1 bus 2
 re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E
 (0x2c00), msi, address 1c:6f:65:37:0b:37
 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
 ehci1 at pci0 dev 29 function 0 Intel 3400 USB rev 0x06: apic 0 int 23
 usb1 at ehci1: USB revision 2.0
 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
 ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xa6
 pci3 at ppb2 bus 3
 pcib0 at pci0 dev 31 function 0 Intel HM55 LPC rev 0x06
 ahci0 at pci0 dev 31 function 2 Intel 3400 AHCI rev 0x06: msi, AHCI 1.3
 scsibus1 at ahci0: 32 targets
 sd0 at scsibus1 targ 0 lun 0: ATA, INTEL SSDSC2CW12, 400i SCSI3 0/direct
 fixed naa.5001517bb2a82d7e
 sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
 ichiic0 at pci0 dev 31 function 3 Intel 3400 SMBus rev 0x06: apic 0 int 18
 iic0 at ichiic0
 spdmem0 at iic0 

Re: nov 18 snaps crashed on amd64.

[Mike Larkin]

On Fri, Nov 21, 2014 at 08:13:56AM +0100, Reyk Floeter wrote:
 
  Am 21.11.2014 um 07:49 schrieb Ted Unangst t...@tedunangst.com:
  
  On Thu, Nov 20, 2014 at 21:46, Janne Johansson wrote:
  short version from the serial console:
  
  
  OpenBSD/amd64 (hostname) (tty00)
  
  
  login: uvm_fault(0x81901260, 0x5c, 0, 1) - e
  
  CPU4: acpicpu setperf failed to alter frequency
  
  The current theory is this is fallout from the recently backed out
  libc string asm change.
  
 
 The libc string asm change was first published Nov 19 and committed yesterday 
 - it was not in the Nov 18 snap.
 
 Reyk
 
 

I think it's unclear what snap that actually was.

And the trap code is invalid instruction. I looked in my objdump and there's a
nop sled there, which is what was being corrupted by the libc string asm change.

It's possible it's unrelated, but it's exactly the same symptoms.

-ml

Re: kernel builded from -current source not boot anymore

[Mike Larkin]

On Fri, Dec 19, 2014 at 03:47:04PM +0100, Jiri Navratil wrote:
 I was able to return to working kernel via
 
 cvs -d$CVSROOT up -Pd -D 20141107
 Sticky Date: 2014.11.06.23.01.00
 
 I can boot to mp kernel again. dmesg from that kernel is attached.
 
 I'm not able to boot to kernel created from this source
 
 # cvs -d$CVSROOT up -Pd -D 20141109
 Sticky Date: 2014.11.08.23.01.00
 
 I found, that these amd64 kernel files were adjusted
 RCS file: /cvs/src/sys/arch/amd64/amd64/hibernate_machdep.c,v
 RCS file: /cvs/src/sys/arch/amd64/amd64/locore.S,v
 RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
 RCS file: /cvs/src/sys/arch/amd64/amd64/pmap.c,v
 RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
 

Well this was likely one or more of the diffs I put in to fix NX on
amd64. But your description of not able to boot doesn't really tell
me what's failing. Does it reboot? Does it hang? Does it panic?

Also please try -current (eg, from today) and not some tree from over
a month ago. I've been making regular changes, and at least one point,
the tree was broken.

-ml

 brief diff is attached
 
 Any idea, which changes had stoped booting on my machine and how to fix
 it? I wish to follow current again. Thank you
 
 Best regards,
 Jiri

 OpenBSD 5.6-current (GENERIC.MP) #12: Fri Dec 19 13:04:53 CET 2014
 r...@berend.navratil.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 2010312704 (1917MB)
 avail mem = 1952980992 (1862MB)
 warning: no entropy supplied by boot loader
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba70 (21 entries)
 bios0: vendor American Megatrends Inc. version X200CA.203 date 07/11/2013
 bios0: ASUSTeK COMPUTER INC. X200CA
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC FPDT ECDT MCFG HPET SSDT SSDT SSDT SSDT MSDM
 acpi0: wakeup devices P0P1(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) XHC1(S3) 
 EHC1(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) 
 USB7(S3) HDEF(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Celeron(R) CPU 1007U @ 1.50GHz, 1496.85 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 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 99MHz
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Celeron(R) CPU 1007U @ 1.50GHz, 1496.61 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 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
 acpiec0 at acpi0
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (P0P1)
 acpiprt2 at acpi0: bus -1 (PEG0)
 acpiprt3 at acpi0: bus -1 (PEG1)
 acpiprt4 at acpi0: bus -1 (PEG2)
 acpiprt5 at acpi0: bus -1 (PEG3)
 acpiprt6 at acpi0: bus 1 (RP01)
 acpiprt7 at acpi0: bus -1 (RP03)
 acpiprt8 at acpi0: bus -1 (RP05)
 acpiprt9 at acpi0: bus -1 (RP06)
 acpiprt10 at acpi0: bus -1 (RP07)
 acpiprt11 at acpi0: bus -1 (RP08)
 acpiprt12 at acpi0: bus 2 (RP02)
 acpiprt13 at acpi0: bus 3 (RP04)
 acpicpu0 at acpi0: C2, C1, PSS
 acpicpu1 at acpi0: C2, C1, PSS
 acpitz0 at acpi0: critical temperature is 108 degC
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT0 model X200-30 serial   type LIon oem ASUSTeK
 acpibtn0 at acpi0: LID_
 acpibtn1 at acpi0: SLPB
 acpivideo0 at acpi0: GFX0
 acpivout0 at acpivideo0: LCDD
 cpu0: Enhanced SpeedStep 1496 MHz: speeds: 1500, 1400, 1300, 1200, 1100, 
 1000, 900, 800 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09
 vga1 at pci0 dev 2 function 0 Intel HD Graphics 2500 rev 0x09
 intagp at vga1 not configured
 inteldrm0 at vga1
 drm0 at inteldrm0
 drm: Memory usable by graphics device = 2048M
 inteldrm0: 1366x768
 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
 wsdisplay0: screen 1-5 added (std, vt100 emulation)
 Intel 7 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured
 Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
 ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
 azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: 

Re: Screen remains blank after suspend

[Mike Larkin]

On Sun, Feb 01, 2015 at 01:42:13PM -0700, Theo de Raadt wrote:
  On Sun, Feb 01, 2015 at 08:35:40PM +0100, lsang...@riseup.net wrote:
   Hi,
   
   there is a problem with suspend on my laptop (Schenker FL90). When
   opening the lid after a suspend the screen remains turned off. But
   the system itself seems to come back well (I can put in the password
   blindly and reboot). The behavior is reproducible and also occurs
   when I type 'zzz' and let the lid open.
   
   /var/log/messages only tells:
   Feb  1 13:10:21 hostname apmd: system suspending
   
  
  Based on the dmesg below, you have a radeon video card. We don't support
  resuming that. Sorry.
 
 Mike means Nvidia.  We cannot resume them.

Sorry, yes. It's early and I haven't had my coffee yet :)

Re: Screen remains blank after suspend

[Mike Larkin]

On Sun, Feb 01, 2015 at 08:35:40PM +0100, lsang...@riseup.net wrote:
 Hi,
 
 there is a problem with suspend on my laptop (Schenker FL90). When
 opening the lid after a suspend the screen remains turned off. But
 the system itself seems to come back well (I can put in the password
 blindly and reboot). The behavior is reproducible and also occurs
 when I type 'zzz' and let the lid open.
 
 /var/log/messages only tells:
 Feb  1 13:10:21 hostname apmd: system suspending
 

Based on the dmesg below, you have a radeon video card. We don't support
resuming that. Sorry.

You might try 'ZZZ' (hibernate), it may have a better time with the card
because it resumes from cold. But maybe not.

-ml

 dmesg:
 OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 4276944896 (4078MB)
 avail mem = 4154310656 (3961MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xdc010 (24 entries)
 bios0: vendor COMPAL version 1.18 date 06/18/2008
 bios0: - N/A
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC HPET MCFG TCPA TMOR SLIC APIC BOOT SSDT
 SSDT SSDT SSDT
 acpi0: wakeup devices HDEF(S4) PXSX(S5)
 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)2 Duo CPU T5750 @ 2.00GHz, 1995.33 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF
 cpu0: 2MB 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 166MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz, 1995.00 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF
 cpu1: 2MB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 2, remapped to apid 1
 acpihpet0 at acpi0: 14318179 Hz
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 1 (PEGP)
 acpiprt2 at acpi0: bus 2 (RP01)
 acpiprt3 at acpi0: bus 4 (RP02)
 acpiprt4 at acpi0: bus 6 (RP03)
 acpiprt5 at acpi0: bus 8 (RP04)
 acpiprt6 at acpi0: bus 10 (RP05)
 acpiprt7 at acpi0: bus 12 (RP06)
 acpiprt8 at acpi0: bus 14 (PCIB)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpibtn0 at acpi0: LID0
 acpibtn1 at acpi0: PWRB
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT1 model PA3465U  serial 3658Q type Li-Ion
 oem COMPAL  
 acpivideo0 at acpi0: VGA_
 acpivout0 at acpivideo0: LCD_
 acpivideo1 at acpi0: GFX0
 acpivout1 at acpivideo1: DD03
 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2000, 1667, 1333, 1000 MHz
 pci0 at mainbus0 bus 0
 0:28:0: bridge mem address conflict 0xbc00/0x400
 0:28:3: bridge mem address conflict 0xb400/0x400
 pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c
 ppb0 at pci0 dev 1 function 0 Intel GM965 PCIE rev 0x0c: msi
 pci1 at ppb0 bus 1
 vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8600M GT rev 0xa1
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x03: apic 1
 int 16
 uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x03: apic 1
 int 21
 ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x03: apic 1
 int 18
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
 azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x03: msi
 azalia0: codecs: Realtek ALC268, Motorola/0x3055, using Realtek ALC268
 audio0 at azalia0
 ppb1 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x03: msi
 pci2 at ppb1 bus 2
 ppb2 at pci0 dev 28 function 1 Intel 82801H PCIE rev 0x03: msi
 pci3 at ppb2 bus 4
 bge0 at pci3 dev 0 function 0 Broadcom BCM5787M rev 0x02,
 BCM5754/5787 A2 (0xb002): msi, address 00:1b:38:6c:c6:b5
 brgphy0 at bge0 phy 1: BCM5787 10/100/1000baseT PHY, rev. 0
 ppb3 at pci0 dev 28 function 2 Intel 82801H PCIE rev 0x03: msi
 pci4 at ppb3 bus 6
 ppb4 at pci0 dev 28 function 3 Intel 82801H PCIE rev 0x03: msi
 pci5 at ppb4 bus 8
 ppb5 at pci0 dev 28 function 4 Intel 82801H PCIE rev 0x03: msi
 pci6 at ppb5 bus 10
 ppb6 at pci0 dev 28 function 5 Intel 82801H PCIE rev 0x03: msi
 pci7 at ppb6 bus 12
 iwn0 at pci7 dev 0 function 0 Intel WiFi Link 5300 rev 0x00: msi,
 MIMO 3T3R, MoW, address 00:16:ea:8e:2a:10
 uhci2 at pci0 dev 29 function 0 Intel 82801H USB rev 0x03: 

Re: Initial suspend/resume cycle needed for ThinkPad ACPI to correctly work

[Mike Larkin]

On Sun, Jan 04, 2015 at 11:42:19PM +0100, Henrik Friedrichsen wrote:
 Hey,
 
 On Sun, Jan 04, 2015 at 01:45:45PM -0800, Mike Larkin wrote:
  There are a few devs with x220 machines and nobody else has seen this
  behavior. Can you see if this happens differently if you boot on AC vs
  booting on battery? (Just a guess).
 
 Nope, did not make a difference. I couldn't determine a pattern yet in
 when it occurs. The next time it does I'll see if I did anything out of
 the ordinary. It definitely doesn't happen all the time, but I remember
 encountering it again a few days ago..

Thanks. I asked around, nobody else seems to be having the problem.

There may be a BIOS setting to set the performance mode, maybe changing
that could have an effect?

-ml

Re: Initial suspend/resume cycle needed for ThinkPad ACPI to correctly work

[Mike Larkin]

On Fri, Nov 14, 2014 at 12:49:42PM +0100, Henrik Friedrichsen wrote:
 Synopsis:Initial suspend/resume cycle needed for ThinkPad ACPI to 
 correctly work
 Category:kernel
 Environment:
   System  : OpenBSD 5.6
   Details : OpenBSD 5.6-current (GENERIC.MP) #556: Wed Nov 12 
 12:33:18 MST 2014

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
 Several ACPI functions do not seem to work after a fresh boot, unless a
 suspend/resume cycle was performed, e.g. with 'zzz'.
 These functions include the brightness keys on my X220 and also the 
 detection
 of a lid-close event (a suspend was never triggered after closing the lid 
 in my case).
 Other ThinkPad models seem to be affected:
 http://marc.info/?l=openbsd-miscm=140381925116673w=2
 How-To-Repeat:
 Using the brightness keys or suspend on lid after a fresh boot
 Fix:
 A suspend/resume cycle seems to work around it
 

There are a few devs with x220 machines and nobody else has seen this
behavior. Can you see if this happens differently if you boot on AC vs
booting on battery? (Just a guess).

-ml

 
 dmesg:
 OpenBSD 5.6-current (GENERIC.MP) #556: Wed Nov 12 12:33:18 MST 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8335577088 (7949MB)
 avail mem = 8109858816 (7734MB)
 warning: no entropy supplied by boot loader
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries)
 bios0: vendor LENOVO version 8DET69WW (1.39 ) date 07/18/2013
 bios0: LENOVO 4290W1A
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA 
 SSDT SSDT UEFI UEFI UEFI
 acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) 
 EHC2(S3) HDEF(S4)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 797.54 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
 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 99MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 797.41 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 1, core 0, package 0
 cpu2 at mainbus0: apid 2 (application processor)
 cpu2: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 797.41 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu2: smt 0, core 1, package 0
 cpu3 at mainbus0: apid 3 (application processor)
 cpu3: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz, 797.41 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
 cpu3: 256KB 64b/line 8-way L2 cache
 cpu3: smt 1, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpiec0 at acpi0
 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 5 (EXP4)
 acpiprt5 at acpi0: bus 13 (EXP5)
 acpiprt6 at acpi0: bus -1 (EXP7)
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpicpu2 at acpi0: C3, C2, C1, PSS
 acpicpu3 at acpi0: C3, C2, C1, PSS
 acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
 acpitz0 at acpi0: critical temperature is 99 degC
 acpibtn0 at acpi0: LID_
 acpibtn1 at acpi0: SLPB
 acpibat0 at acpi0: BAT0 model 42T4861 serial  5714 type LION oem SANYO
 acpibat1 at acpi0: BAT1 not present
 acpiac0 at acpi0: AC unit offline
 acpithinkpad0 at acpi0
 acpidock0 at acpi0: GDCK not docked (0)
 cpu0: Enhanced SpeedStep 797 MHz: speeds: 2100, 2000, 1900, 1800, 1700, 1600, 
 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
 pci0 at mainbus0 

Re: uvm_fault with bwi on i386 when scanning or bringing up.

[Mike Larkin]

On Thu, Feb 19, 2015 at 09:02:42PM -0330, Michael wrote:
 
  There's a slim chance that killing processes (sshd, smtpd, dhclient,
  cron, pflogd, ntpd) might free up enough to help.
 
  Maybe also worth trying ddb.console=0, it will try to print a stack
  trace and then reboot rather than entering ddb.
 
 
 New and updated output after stopping the processes and setting
 ddb.console=0, however ddb is still entered and there wasn't a stack
 trace.

I think ddb.panic was what he meant?

-ml

 
 sudo ifconfig bwi0 up
 uvm_fault(0xd211a6c0, 0x0, 0, 1) - e
 kernel: page fault trap, code=0
 Stopped at  0:uvm_fault(0xd211a6c0, 0x0, 0, 1) - e
   kernel: page fault trap, code=0
 Stopped at  db_read_bytes+0x17: movzbl  0(%esi,%ecx,1),%eax
 
 
 ddb ps
PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 *29704  16328  29704  0  7 0x3ifconfig
  16328  1  16328   1000  30x8b  pause ksh
  14833  26227  26227 73  20x90syslogd
  26227  1  26227  0  30x80  netio syslogd
  17845  0  0  0  2 0x14200zerothread
  18141  0  0  0  3 0x14200  aiodoned  aiodoned
   1894  0  0  0  3 0x14200  syncerupdate
  27861  0  0  0  3 0x14200  cleaner   cleaner
  23566  0  0  0  3 0x14200  reaperreaper
  11132  0  0  0  3 0x14200  pgdaemon  pagedaemon
  28889  0  0  0  3 0x14200  bored crypto
   7559  0  0  0  3 0x14200  pftm  pfpurge
  22720  0  0  0  3 0x14200  bored systqmp
  23801  0  0  0  3 0x14200  bored systq
  18116  0  0  0  3  0x40014200idle0
  12202  0  0  0  3 0x14200  kmalloc   kmthread
  1  0  1  0  30x82  wait  init
  0 -1  0  0  3 0x10200  scheduler swapper
 
 ddb show registers
 ds  0x10
 es  0x10
 fs  0x20
 gs 0
 edi   0xf11adae0
 esi0
 ebp   0xf11adac4
 ebx  0x1
 edx   0xf11adae0
 ecx0
 eax0
 eip   0xd055a447db_read_bytes+0x17
 cs   0x8
 eflags   0x10246
 esp   0xf11adaac
 ss  0x10
 db_read_bytes+0x17: movzbl  0(%esi,%ecx,1),%eax
 
 ddb dmesg
 OpenBSD 5.7-beta (GENERIC) #714: Tue Feb 17 12:45:41 MST 2015
 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
 cpu0: AMD Am5x86 W/B 133/160 (AuthenticAMD 486-class)
 cpu0: FPU
 real mem  = 66600960 (63MB)
 avail mem = 53186560 (50MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: date 20/80/03, BIOS32 rev. 0 @ 0xf7840
 pcibios0 at bios0: rev 2.0 @ 0xf/0x1
 pcibios0: pcibios_get_intr_routing - function not supported
 pcibios0: PCI IRQ Routing information unavailable.
 pcibios0: PCI bus #0 is the last bus
 bios0: ROM list: 0xc8000/0x9000
 cpu0 at mainbus0: (uniprocessor)
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 elansc0 at pci0 dev 0 function 0 AMD ElanSC520 PCI rev 0x00: product 0 
 steppi
 ng 1.1, CPU clock 133MHz, reset 40SCP
 gpio0 at elansc0: 32 pins
 bwi0 at pci0 dev 16 function 0 Broadcom BCM4306 rev 0x02: irq 10, address 
 00:
 90:4b:72:9f:fd
 sis0 at pci0 dev 18 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 
 11, a
 ddress 00:00:24:c4:e7:60
 nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
 sis1 at pci0 dev 19 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 5, 
 a
 ddress 00:00:24:c4:e7:61
 nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
 sis2 at pci0 dev 20 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 9, 
 a
 ddress 00:00:24:c4:e7:62
 nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
 isa0 at mainbus0
 isadma0 at isa0
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com0: console
 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
 pckbc0 at isa0 port 0x60/5
 pckbd0 at pckbc0 (kbd slot)
 pckbc0: using irq 1 for kbd slot
 wskbd0 at pckbd0: console keyboard
 wdc0 at isa0 port 0x1f0/8 irq 14
 wd0 at wdc0 channel 0 drive 0: SanDisk SDCFH-004G
 wd0: 1-sector PIO, LBA48, 3815MB, 7813120 sectors
 wd0(wdc0:0:0): using BIOS timings
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
 vscsi0 at root
 scsibus1 at vscsi0: 256 targets
 softraid0 at root
 scsibus2 at softraid0: 256 targets
 root on wd0a (cbaa94e16775c203.a) swap on wd0b dump on wd0b
 uvm_fault(0xd211a6c0, 0x0, 0, 1) - e
 kernel: page fault trap, code=0
 Stopped at  0:  uvm_fault(0xd211a6c0, 0x0, 0, 1) - e
 kernel: page fault trap, code=0
 Stopped at  db_read_bytes+0x17: movzbl  0(%esi,%ecx,1),%eax
 
 Console boot
 OpenBSD 

Re: uvm_fault - Stopped at pmap_remove_ptes_86

[Mike Larkin]

On Tue, Apr 21, 2015 at 11:36:44AM -0400, Daniel Dickman wrote:
 I am seeing the exact same crash with GENRIC.MP latest snap on i386. booting 
 with the GENRIC kernel works for me though.

Thanks for the report. This was likely introduced in 1.175 of i386 pmap.c.
I just committed a fix, should show up in snaps soon.

-ml


 
  On Apr 21, 2015, at 11:19 AM, Mark Patruck m...@wrapped.cx wrote:
  
  I tried source updating my 3 weeks old i386 OpenBSD 5.7-current and
  after booting the new kernel it crashed after fsck'ing. Just to make
  sure, i did an update via latest snapshot, but it crashed again.
  (full dmesg below)
  
  OpenBSD 5.7-current (GENERIC.MP) #824: Mon Apr 20 23:23:30 MDT 2015
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
  cpu0: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (GenuineIntel 686-class) 
  3.30 GHz
  
  setting tty flags
  pf enabled
  ddb.console: 0 - 1
  starting network
  uvm_fault(0xd0b89480, 0xcf9df000, 0, 1) - e
  kernel: page fault trap, code=0
  Stopped at  pmap_remove_ptes_86+0x72:   movl0(%edx),%eax
  ddb{0}
  
  
  ddb{0} trace
  pmap_remove_ptes_86(daa25100,d45c4f30,cf9dfd60,77f58000,77f59000) at 
  pmap_remov
  e_ptes_86+0x72
  pmap_do_remove_86(daa25100,77f58000,77f59000,0,daa2a2bc) at 
  pmap_do_remove_86+0
  xfc
  pmap_remove(daa25100,77f58000,77f59000,d04fc9c9,d0ba7e60) at 
  pmap_remove+0x28
  uvm_unmap_kill_entry(daa26120,daa0a580,f54c1f2c,d050bdcd,daa0a580) at 
  uvm_unmap
  _kill_entry+0xf8
  uvm_map_teardown(daa26120,f54c1f14,2e770bc0,daa0b008,d03a23f0) at 
  uvm_map_teard
  own+0xbc
  uvmspace_free(daa26120,1,2e770bc0,f54c1f5c,d02032fa) at uvmspace_free+0x2e
  uvm_exit(daa1c310,d0b23ac8,4,d09aac8e,0) at uvm_exit+0x15
  reaper(daa2270c) at reaper+0xd0
  
  
  ddb{0} ps
PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
  30843  30854  30854  0  30x8b  pause sh
  30854  1  30854  0  30x8b  pause sh
  10796  0  0  0  3 0x14200  pgzerozerothread
  20524  0  0  0  3 0x14200  aiodoned  aiodoned
  30711  0  0  0  3 0x14200  syncerupdate
295  0  0  0  3 0x14200  cleaner   cleaner
  *18600  0  0  0  7 0x14200reaper
   8467  0  0  0  3 0x14200  pgdaemon  pagedaemon
  21165  0  0  0  3 0x14200  bored crypto
  22401  0  0  0  3 0x14200  pftm  pfpurge
  21731  0  0  0  3 0x14200  usbtskusbtask
  13690  0  0  0  3 0x14200  usbatsk   usbatsk
   1565  0  0  0  3 0x14200  bored sensors
  11166  0  0  0  3  0x40014200  acpi0 acpi0
  32510  0  0  0  7  0x40014200idle3
   7402  0  0  0  7  0x40014200idle2
  14316  0  0  0  7  0x40014200idle1
  28105  0  0  0  3 0x14200  bored softnet
  11715  0  0  0  3 0x14200  bored systqmp
   6918  0  0  0  3 0x14200  bored systq
   4056  0  0  0  3  0x40014200idle0
  24258  0  0  0  3 0x14200  kmalloc   kmthread
  1  0  1  0  30x82  wait  init
  0 -1  0  0  3 0x10200  scheduler swapper
  
  
  ddb{0} show registers
  ds  0x10
  es  0x10
  fs  0x20
  gs 0
  edi   0x77f58000
  esi   0x77f58000
  Ebp   0xf54c1e2c
  ebx   0x77f59000
  edx   0xcf9dfd60PTmap+0x1dfd60
  ecx   0xdaa25100end+0x9ddbe18
  eax   0xd45c4f30end+0x397bc48
  eip   0xd0564ab2pmap_remove_ptes_86+0x72
  cs   0x8
  eflags   0x10202
  esp   0xf54c1de4
  ss  0x10
  pmap_remove_ptes_86+0x72:   movl0(%edx),%eax
  
  
  OpenBSD 5.7-current (GENERIC.MP) #824: Mon Apr 20 23:23:30 MDT 2015
 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
  cpu0: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (GenuineIntel 686-class) 
  3.30 GHz
  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,NXE,PAGE1GB,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
  real mem  = 3715575808 (3543MB)
  avail mem = 3642568704 (3473MB)
  mpath0 at root
  scsibus0 at mpath0: 256 targets
  mainbus0 at root
  bios0 at mainbus0: date 04/13/12, SMBIOS rev. 2.7 @ 0xec090 (36 entries)
  bios0: vendor American Megatrends Inc. version 1.1a date 12/03/2013
  bios0: Supermicro X10SLH-F/X10SLM+-F
  acpi0 at bios0: rev 2

Re: suspend drops acpi

[Mike Larkin]

On Sat, Jul 04, 2015 at 10:28:02AM +0200, Martijn van Duren wrote:
 Hello bugs@,
 
 I recently bought a second hand laptop (Acer Aspire 5742) and for
 the biggest part it works great for my needs. Suspending also works,
 but after resume acpi doesn't seem to work anymore: A second suspend
 isn't possible and a shutdown -p results in a press key to reboot.
 
 Since attachments aren't allowed on bugs@ I've placed the dmesg (pre
 and post suspend) with a full acpidump(8) at
 http://imperialat.at/suspend.tar.gz 
 (sha256=0dcb7e634a5c28c475c5ec8c5b521082e76b58a7826877c12a80d3f682fa0676)
 
 Hope the information is sufficient.
 
 Sincerely,
 
 Martijn van Duren
 

Can you please send this via sendbug so we all have the information
in one place?

Re: [acpi] kernel diagnostic assertion (reg 0x3) == 0 failed

[Mike Larkin]

On Sat, Jul 25, 2015 at 03:44:26PM +0200, giova...@paclan.it wrote:
 Synopsis:after acpi.c 1.289 commit my laptop cannot boot anymore
 Category:kernel
 Environment:
   System  : OpenBSD 5.8
   Details : OpenBSD 5.8-beta (GENERIC.MP) #20: Wed Jul 22 13:24:32 
 CEST 2015

 giova...@bigio.paclan.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
   laptop cannot boot and enters ddb, kernel in dmesg is built
 from src tree as of 07/22 with acpi.c rev 1.288

I think this is fixed by the recent acpi.c revert.

-ml

 ---
 Jul 22 13:07:57 bigio /bsd: cpu3: 256KB 64b/line 8-way L2 cache
 Jul 22 13:07:57 bigio /bsd: cpu3: smt 1, core 1, package 0
 Jul 22 13:07:57 bigio /bsd: ioapic0 at mainbus0: apid 2 pa 0xfec0, 
 version 20, 24 pins
 Jul 22 13:07:57 bigio /bsd: acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 Jul 22 13:07:57 bigio /bsd: panic: kernel diagnostic assertion (reg  0x3) 
 == 0 failed: file ../../../../arch/amd64/pci/pci_machdep.c, line 272
 Jul 22 13:07:57 bigio /bsd: Stopped atDebugger+0x9:   leave   
 Jul 22 13:07:57 bigio /bsd: Debugger() at Debugger+0x9
 Jul 22 13:07:57 bigio /bsd: panic() at panic+0xfe
 Jul 22 13:07:57 bigio /bsd: __assert() at __assert+0x25
 Jul 22 13:07:57 bigio /bsd: pci_conf_read() at pci_conf_read+0x103
 Jul 22 13:07:57 bigio /bsd: acpi_gasio() at acpi_gasio+0x41d
 Jul 22 13:07:57 bigio /bsd: aml_rwgas() at aml_rwgas+0x2e7
 Jul 22 13:07:57 bigio /bsd: aml_rwfield() at aml_rwfield+0x205
 Jul 22 13:07:57 bigio /bsd: aml_store() at aml_store+0x1eb
 Jul 22 13:07:57 bigio /bsd: aml_parse() at aml_parse+0xf4c
 Jul 22 13:07:57 bigio /bsd: aml_eval() at aml_eval+0x1c8
 Jul 22 13:07:57 bigio /bsd: end trace frame: 0x81a28990, count: 0
 Jul 22 13:07:57 bigio /bsd: RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT 
 WHEN REPORTING THIS PANIC!
 Jul 22 13:07:57 bigio /bsd: IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' 
 ON OTHER PROCESSORS, TOO.
 Jul 22 13:07:57 bigio /bsd: DO NOT EVEN BOTHER REPORTING THIS WITHOUT 
 INCLUDING THAT INFORMATION!
 Jul 22 13:07:57 bigio /bsd: ddb{0} Debugger() at Debugger+0x9
 Jul 22 13:07:57 bigio /bsd: panic() at panic+0xfe
 Jul 22 13:07:57 bigio /bsd: __assert() at __assert+0x25
 Jul 22 13:07:57 bigio /bsd: pci_conf_read() at pci_conf_read+0x103
 Jul 22 13:07:57 bigio /bsd: acpi_gasio() at acpi_gasio+0x41d
 Jul 22 13:07:57 bigio /bsd: aml_rwgas() at aml_rwgas+0x2e7
 Jul 22 13:07:57 bigio /bsd: aml_rwfield() at aml_rwfield+0x205
 Jul 22 13:07:57 bigio /bsd: aml_store() at aml_store+0x1eb
 Jul 22 13:07:57 bigio /bsd: aml_parse() at aml_parse+0xf4c
 Jul 22 13:07:57 bigio /bsd: aml_eval() at aml_eval+0x1c8
 Jul 22 13:07:57 bigio /bsd: aml_evalnode() at aml_evalnode+0x74
 Jul 22 13:07:57 bigio /bsd: acpi_inidev() at acpi_inidev+0x57
 Jul 22 13:07:57 bigio /bsd: aml_find_node() at aml_find_node+0x92
 Jul 22 13:07:57 bigio /bsd: aml_find_node() at aml_find_node+0x87
 Jul 22 13:07:57 bigio last message repeated 3 times
 Jul 22 13:07:57 bigio /bsd: acpi_attach() at acpi_attach+0x496
 Jul 22 13:07:57 bigio /bsd: config_attach() at config_attach+0x1bc
 Jul 22 13:07:57 bigio /bsd: bios_attach() at bios_attach+0x23b
 Jul 22 13:07:57 bigio /bsd: config_attach() at config_attach+0x1bc
 Jul 22 13:07:57 bigio /bsd: mainbus_attach() at mainbus_attach+0x66
 Jul 22 13:07:57 bigio /bsd: config_attach() at config_attach+0x1bc
 Jul 22 13:07:57 bigio /bsd: cpu_configure() at cpu_configure+0x1b
 Jul 22 13:07:57 bigio /bsd: main() at main+0x40d
 Jul 22 13:07:57 bigio /bsd: end trace frame: 0x0, count: -25
 Jul 22 13:07:57 bigio /bsd: ddb{0}PID   PPID   PGRPUID  S   
 FLAGS  WAIT  COMMAND 
 Jul 22 13:07:57 bigio /bsd: *0 -1  0  0  7 0x10200
 swapper 
 ---
 
 How-To-Repeat:
   just boot the laptop with acpi.c 1.289 applied
 Fix:
   as a workaround I backout acpi.c to a previous revision on my tree
 
 
 dmesg:
 OpenBSD 5.8-beta (GENERIC.MP) #20: Wed Jul 22 13:24:32 CEST 2015
 giova...@bigio.paclan.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 3835400192 (3657MB)
 avail mem = 3715264512 (3543MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae3a000 (60 entries)
 bios0: vendor LENOVO version H5ET69WW (1.12 ) date 11/15/2012
 bios0: LENOVO 62742QG
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI 
 UEFI MSDM UEFI DBG2
 acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S4) 
 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, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) 

Re: HP elitebook 840 G2 sleep/resume error

[Mike Larkin]

On Wed, Aug 12, 2015 at 05:53:55PM -0700, Mike Larkin wrote:
 On Wed, Aug 12, 2015 at 02:09:21PM +0200, so...@aurehoej.net wrote:
  Synopsis: Unable to go into sleep/hibernate, screen goes blank - machine 
  runs 
  Category:  system  
  Environment:
  System  : OpenBSD 5.8
  Details : OpenBSD 5.8 (GENERIC.MP) #1235: Mon Aug 10 06:54:34 MDT 
  2015
   
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
  Architecture: OpenBSD.amd64
  Machine : amd64
  Description:
  when going to sleep via zzz or closing the lid on the laptop the 
  machine the log /var/log/daemon tells apmd: system suspending. Immediately 
  after it says system resumed from sleep and start issuing dhcp requests. At 
  no point is the machine nonresponsive if logged in from the another 
  machine. The problem is that the screen and keyboard appears to sleep, but 
  everything else is still on. I have tried 5.6, 5.7 and daily snapshots for 
  3 weeks. Machdep.lidsuspend=0|1, various settings in BIOS, updating BIOS - 
  all with the same result. 
  How-To-Repeat:
  start apmd, press zzz or close lid.  
  Fix:
  None known.
 
 Based on this email and other's we've exchanged, I believe this is
 actually two different problems:
 
 1. You are waking spontaneously, probably a botched GPE or we didn't 
 eval _PSW properly on some of these objects. The fact that you say the
 machine resumes immediately from S3 (zzz) *and* S4 (ZZZ) *and* S5
 (halt -p) implies one of these S5 resume devices is firing unexpectedly.
 
 LANC(S5) PCIB(S5) RP03(S5) NIC_(S5) RP04(S5) WNIC(S5) HST1(S5)
 
 2. You have broadwell video, and we already know we don't do well
 resuming that. That's why your video doesn't repost after S3 (zzz) but
 works fine after S4 (ZZZ). I'm afraid there's not much you can do here
 except wait for better support (which some devs are working on), or
 use ZZZ instead until proper broadwell support goes in.
 
 I will see if I can track down if I can tell which device is doing
 the wake, and will work with you off-list.
 
 -ml

This seems to be a problem with Linux as well:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1470723

.. still investigating.

-ml

Re: 5.8 kernel 1305 crashes during boot on i386/VIA

[Mike Larkin]

On Sun, Nov 08, 2015 at 11:35:05PM -0500, gwes wrote:
> >Date: Sun, 8 Nov 2015 23:10:14 -0500 (EST)
> >Message-Id: <12236891800431900475.enqu...@river.oat.com>
> >To: bugs@openbsd.org
> >Subject: 5.8 snap fails early in boot
> >From: gwes
> >Cc: gwes
> >Reply-To: gwes
> 
> >Synopsis:  5.8 kernel 1305 fails to boot. Generic 5.8 works
> >Category:  i386
> >Environment:
> System  : OpenBSD 5.8
> Details : OpenBSD 5.8 (GENERIC) #1066: Sun Aug 16 02:33:00 MDT
> 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> 
> Architecture: OpenBSD.i386
> Machine : i386
> >Description:
> uvm fault early in booting process. The traceback looks like
> the fault is in ddb? but that is probably an artifact.
> The release 5.8 kernel boots & runs.
> >How-To-Repeat:
> boot snapshots kernel 1305 on a VIA chip i386
> >Fix:
> not known
> config(8) changed since release so attempts to build a debugging
> kernel have failed - the new config depends on the new kernel :-(
> 
> If there is a repository of snapshots I can search through them
> looking for the first one that fails
> 
> If it's likely that building config(8) from old sources without
> pledge(2) pointed at new .h files would work I can try that.
> 
> console output:
> booting hd0a:bsd.1: 7698276+2034536+189444+0+1069056
> [72+414928+409752]=0xb4674c
> entry point at 0x2000d4
> 
> [ using 825164 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-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org
> 
> OpenBSD 5.8-current (GENERIC) #1305: Fri Nov  6 05:20:32 MST 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2
> real mem  = 1005010944 (958MB)
> avail mem = 973246464 (928MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 05/16/06, BIOS32 rev. 0 @ 0xfb570, SMBIOS rev. 2.3 @
> 0xf (34 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 05/16/2006
> acpi at bios0 function 0x0 not configured

Does acpi always come up as not configured, even when running the 5.8 release
kernel? or did you disable it?

> apm0 at bios0uvm_fault(0xd0b9b640, 0xd0dad000, 0, 4) -> d
> kernel: page fault trap, code=0
> Stopped at  __ALIGN_SIZE+0x706c:uvm_fault(0xd0bbd0a0, 0x8000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  db_read_bytes+0x17: movzbl 0(%esi,%ecx,1),%eax
> ddb> where
> No such command
> ddb> trace
> db_read_bytes(806c,1,d0d489e0,806c,d0d489f0) at db_read_bytes+0x17
> db_get_value(806c,1,0,0,d09fee1a) at db_get_value+0x38
> db_disasm(806c,0,d03cc820,d03cc845,d09d3878,d0d48ab0,0,0,d0d48ab0) at
> db_disasm
> +0x31
> db_print_loc_and_inst(806c,d0d48ac8,d0d48ad4,d03cc845,d09fee0b) at
> db_print_loc
> _and_inst+0x3e
> db_trap(6,0,58,0,d0d48b10) at db_trap+0x8d
> kdb_trap(6,0,d0d48b80,4,d) at kdb_trap+0xcc
> trap() at trap+0x2a5
> --- trap (number 21262) ---
> 0x11:
> ddb> show reg]
> Bad character
> ds  0x10
> es  0x10
> fs  0x20
> gs 0
> edi   0xd0d489e0__kernel_bss_end+0xcb9e0
> esi   0x806c__ALIGN_SIZE+0x706cebp 0xd0d489c4
> __kernel_bss_end+0xcb9c4
> ebx  0x1
> edx   0xd0d489e0__kernel_bss_end+0xcb9e0
> ecx0
> eax   0x806c__ALIGN_SIZE+0x706c
> eip   0xd0558b17db_read_bytes+0x17
> cs   0x8
> eflags   0x10046__ALIGN_SIZE+0xf046
> esp   0xd0d489ac__kernel_bss_end+0xcb9ac
> ss  0x10
> dmesg:
> OpenBSD 5.8 (GENERIC) #1066: Sun Aug 16 02:33:00 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.51
> GHzFXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2
> real mem  = 1005010944 (958MB)
> avail mem = 972529664 (927MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 05/16/06, BIOS32 rev. 0 @ 0xfb570, SMBIOS rev. 2.3 @
> 0xf (34 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 05/16/2006
> acpi at bios0 function 0x0 not configured
> apm0 at bios0: Power Management spec V1.2 (slowidle)
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
> cpu0: apic clock running at 100MHz
> mpbios0: bus 0 is type PCI
> mpbios0: bus 1 is type PCI
> mpbios0: bus 2 is type ISA

Re: i386-current bsd.rd fails on net6501

[Mike Larkin]

On Tue, Sep 08, 2015 at 08:02:45PM +0200, Christian Weisgerber wrote:
> Mark Kettenis:
> 
> > Does the bsd kernel from the same snapshot blow up as well?
> 
> Yes.
> 
> booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
> [72+411072+405023]=0xb155c4
> entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]
> 
> [ using 816580 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-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
> 
> OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> real mem  = 1073086464 (1023MB)
> avail mem = 1040211968 (992MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> cpu at mainbus0: not configured
> mpbios0: bus 0 is type PCI   
> mpbios0: bus 64 is type ISA   
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> kernel: page fault trap, code=0
> Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> ddb> 
>

That address and instruction seem bogus. When did it last work?

This seems awfully similar to the other bug we fixed in Calgary a couple
months back; I'm wondering if there is another similar issue. I looked last
time and didn't see anything but may have missed something.
 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Re: i386-current bsd.rd fails on net6501

[Mike Larkin]

On Tue, Sep 08, 2015 at 09:34:04PM +0200, Mark Kettenis wrote:
> > Date: Tue, 8 Sep 2015 12:03:28 -0700
> > From: Mike Larkin <mlar...@azathoth.net>
> > 
> > On Tue, Sep 08, 2015 at 08:02:45PM +0200, Christian Weisgerber wrote:
> > > Mark Kettenis:
> > > 
> > > > Does the bsd kernel from the same snapshot blow up as well?
> > > 
> > > Yes.
> > > 
> > > booting hd0a:bsd.i386: 7520308+2015344+189444+0+1069056 
> > > [72+411072+405023]=0xb155c4
> > > entry point at 0x2000d4 [7205c766, 3404, 24448b12, de60a304]
> > > 
> > > [ using 816580 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-2015 OpenBSD. All rights reserved.  
> > > http://www.OpenBSD.org
> > > 
> > > OpenBSD 5.8-current (GENERIC) #1156: Mon Sep  7 07:02:35 MDT 2015
> > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
> > > cpu0: 
> > > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> > > real mem  = 1073086464 (1023MB)
> > > avail mem = 1040211968 (992MB)
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: date 20/21/15, BIOS32 rev. 0 @ 0xfac40
> > > mpbios0 at bios0: Intel MP Specification 1.4
> > > cpu0 at mainbus0: apid 0 (boot processor)
> > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > > cpu0: apic clock running at 100MHz
> > > cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2.0.3, IBE
> > > cpu at mainbus0: not configured
> > > mpbios0: bus 0 is type PCI   
> > > mpbios0: bus 64 is type ISA   
> > > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> > > uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> > > kernel: page fault trap, code=0
> > > Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> > > ddb> 
> > >
> > 
> > That address and instruction seem bogus. When did it last work?
> 
> Before your i386 W^X commit?
> 

Could be, although I thought I got all the regions that needed executable
bits set for BIOS. I'll take a look.

> 0x49435025 is $PCI aka PCIBIOS_SIGNATURE.  That's pretty strong
> evidence we're in the pcibiosprobe(), doing the bios32_service() call.
> 

Yeah, just noticed that as well. The wrong symbol there threw me off.

-ml

Re: "kernel: page fault trap" / uvm_fault in -current (i386)

[Mike Larkin]

On Tue, Sep 01, 2015 at 09:54:57AM -0400, Andre Smagin wrote:
> Hello.
> 
> Today I tried updating my home firewall to -current and ran into a
> kernel panic. Below are the console outputs from bsd.rd, bsd, and a
> working bsd-current from March.
> 
> The system is an older Portwell NAD-2074 appliance.
> 
> Thank you in advance for your help!
> --
> Andre

I believe this was the same problem previously reported, and if so,
a fix went into snapshots about an hour ago. Wait for the new snap
to appear and give it a try, thanks.

-ml

> 
> bsd.rd:
> ~~~
> 
> >> OpenBSD/i386 BOOT 3.26...  
> >>   
> boot> boot bsd.rd 
>  
> booting hd0a:bsd.rd: 3175988+1310272+2057216+0+425984 
> [72+247664+237984]=0x71daf4
> entry point at 0x2000d4   
>
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
>  
> OpenBSD 5.8-current (RAMDISK_CD) #1093: Tue Sep  1 01:16:57 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> cpu0: VIA C7 Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz   
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2,xTPR
> real mem  = 1274605568 (1215MB)
> avail mem = 1241051136 (1183MB)
> mainbus0 at root   
> bios0 at mainbus0: date 10/09/07, BIOS32 rev. 0 @ 0xf9f70, SMBIOS rev. 2.3 @ 
> 0xf0800 (33 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 10/09/2007 
>
> acpi at bios0 function 0x0 not configured
> apm0 at bios0uvm_fault(0xd08617d4, 0xd0a66000, 0, 4) -> d
> fatal page fault (6) in supervisor mode  
> trap type 6 code 11 eip 80fc cs 38 eflags 10002 cr2 d0a660fc cpl 0
> panic: trap type 6, code=11, pc=80fc  
> 
> The operating system has halted.
> Please press any key to reboot. 
> 
> bsd:
> 
> 
> >> OpenBSD/i386 BOOT 3.26...  
> >>   
> boot> boot bsd.new
>  
> booting hd0a:bsd.new: 7518564+2014480+189444+0+1069056 
> [72+410960+404883]=0xb134c8
> entry point at 0x2000d4   
> 
>
> [ using 816328 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-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
>  
> OpenBSD 5.8-current (GENERIC) #1124: Tue Sep  1 01:06:27 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: VIA C7 Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2,xTPR
> real mem  = 1274560512 (1215MB)
> avail mem = 1237835776 (1180MB)
> mpath0 at root 
> scsibus0 at mpath0: 256 targets
> mainbus0 at root   
> bios0 at mainbus0: date 10/09/07, BIOS32 rev. 0 @ 0xf9f70, SMBIOS rev. 2.3 @ 
> 0xf0800 (33 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 10/09/2007 
>
> acpi at bios0 function 0x0 not configured
> apm0 at bios0uvm_fault(0xd0b6a5e0, 0xd0d7a000, 0, 4) -> d
> kernel: page fault trap, code=0  
> Stopped at  __ALIGN_SIZE+0x70fc:uvm_fault(0xd0b8c000, 0x8000, 0, 1) -> e
> kernel: page fault trap, code=0 
> Stopped at  db_read_bytes+0x17: movzbl  0(%esi,%ecx,1),%eax
> 
> ddb> trace 
> db_read_bytes(80fc,1,d0d159e0,80fc,d0d159f0) at db_read_bytes+0x17
> db_get_value(80fc,1,0,0,d09d2c9a) at db_get_value+0x38
> db_disasm(80fc,0,d03cada0,d03cadc5,d09a77b8,d0d15ab0,0,0,d0d15ab0) at 
> db_disasm
> +0x31 
>  
> db_print_loc_and_inst(80fc,d0d15ac8,d0d15ad4,d03cadc5,d09d2c8b) at 
> db_print_loc
> _and_inst+0x3e
>  
> db_trap(6,0,58,0,d0d15b10) at db_trap+0x8d
> kdb_trap(6,0,d0d15b80,4,d) at kdb_trap+0xcc
> trap() at trap+0x2a5   
> --- trap (number 21262) ---
> 0x11:  
> 
> ddb> ps
>PID   PPID   PGRPUID  S   FLAGS  WAIT  

Re: "kernel: page fault trap" / uvm_fault in -current (i386)

[Mike Larkin]

On Tue, Sep 29, 2015 at 09:47:07PM -0400, Andre Smagin wrote:
> On Tue, 29 Sep 2015 07:43:34 -0700
> Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > I believe this was the same problem previously reported, and if so,
> > a fix went into snapshots about an hour ago. Wait for the new snap
> > to appear and give it a try, thanks.
> > 
> > -ml
> 
> Thank you for looking into the issue, much appreciated!
> 
> The good news is that bsd #1185 now boots without any noticeable
> issues (dmesg at the end).
> 
> The less fortunate news is that bsd.rd fails to boot, but in a
> different way than before:

Ok I see what's going on here. The alignment / padding layout of the
different kernels is killing us. I'll need to sort out the right layout,
shouldn't take too long. Stay tuned.

-ml

> 
> boot> boot bsd.rd 
>  
> booting hd0a:bsd.rd: 3193920+1311488+2057216+0+425984 
> [72+248384+238601]=0x723030
> entry point at 0x2000d4   
>
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
>  
> OpenBSD 5.8-current (RAMDISK_CD) #1151: Tue Sep 29 12:06:03 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> cpu0: VIA C7 Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz   
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2,xTPR
> real mem  = 1274605568 (1215MB)
> avail mem = 1242415104 (1184MB)
> 
> 
> 
> The clicking sounds are normal / the same as when I reboot the
> system manually, as in:
> 
> sudo reboot
> ...
> syncing disks... done
> rebooting... 
> 
> 
> 
> I will be happy to do any other testing if it could be helpful.
> --
> Andre
> 
> 
> dmesg from the latest snapshot bsd:
> 
> boot> boot bsd.new
>  
> booting hd0a:bsd.new: 7692932+2030544+189444+0+1069056 
> [72+414160+409134]=0xb441e4
> entry point at 0x2000d4   
> 
>
> [ using 823780 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-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
>  
> OpenBSD 5.8-current (GENERIC) #1185: Tue Sep 29 11:55:28 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: VIA C7 Processor 1000MHz ("CentaurHauls" 686-class) 1 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,NXE,SSE3,EST,TM2,xTPR
> real mem  = 1274560512 (1215MB)
> avail mem = 1237639168 (1180MB)
> mpath0 at root 
> scsibus0 at mpath0: 256 targets
> mainbus0 at root   
> bios0 at mainbus0: date 10/09/07, BIOS32 rev. 0 @ 0xf9f70, SMBIOS rev. 2.3 @ 
> 0xf0800 (33 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 10/09/2007 
>
> acpi at bios0 function 0x0 not configured
> apm0 at bios0: Power Management spec V1.2 (slowidle)
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)   
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
> cpu0: apic clock running at 99MHz
> mpbios0: bus 0 is type PCI   
> mpbios0: bus 1 is type PCI   
> mpbios0: bus 2 is type ISA   
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 3, 24 pins
> pcibios0 at bios0: rev 2.1 @ 0xf/0xd464  
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd390/208 (11 entries)
> pcibios0: PCI Exclusive IRQs: 5 7 9 10 11 
> pcibios0: PCI Interrupt Router at 000:17:0 ("VIA VT82C596A ISA" rev 0x00)
> pcibios0: PCI bus #1 is the last bus 
> bios0: ROM list: 0xc/0x8000 0xc8000/0xc000!
> cpu0: unknown Enhanced SpeedStep CPU, msr 0x08100a1308000a13
> cpu0: using only highest and lowest power states
> cpu0: Enhanced SpeedStep 998 MHz: speeds: 1333, 1067 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)  

Re: i386-current bsd.rd fails on net6501

[Mike Larkin]

On Tue, Sep 08, 2015 at 10:23:57PM +0200, Christian Weisgerber wrote:
> Mark Kettenis:
> 
> > > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
> > > uvm_fault(0xd0b6c5e0, 0xd0d7e000, 0, 4) -> d
> > > kernel: page fault trap, code=0
> > > Stopped at  __kernel_bss_end+0x130c40:  cmpl$0x49435024,%eax
> > > ddb> 
> > 
> > no trace?
> 
> __kernel_bss_end(49435024,d0c4bf84,d0c4bf8a,e06671f9,7) at 
> __kernel_bss_end+0x1
> 30c40
> pcibiosprobe(d211a0c0,d0b1e7c0,d0d17d2c,d0850965,d0b86508) at 
> pcibiosprobe+0x64
> 
> config_scan(d0b25244,5,0,0,0) at config_scan+0x10e
> config_search(0,d211a0c0,d0d17d2c,0,0) at config_search+0xf4
> config_found_sm(d211a0c0,d0d17d2c,d084c8d0,0,31) at config_found_sm+0x2b
> biosattach(d211a080,d211a0c0,d0d17e40,d03bdf4b,0) at biosattach+0x7e4
> config_attach(d211a080,d0b1e720,d0d17e40,d0590de0,8) at config_attach+0x1bc
> mainbus_attach(0,d211a080,0,d20ea080,0) at mainbus_attach+0x5e
> config_attach(0,d0b1c040,0,0,d0d16000) at config_attach+0x1bc
> config_rootfound(d09d3256,0,7,0,d03bbb80) at config_rootfound+0x46
> cpu_configure(d09a3268,0,1000,cfb3e000,1) at cpu_configure+0x4f
> main(d02004c1,d02004c9,0,0,0) at main+0x3ef
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

The test I used to verify the previous BIOS fix still works, so this may be
a related issue, but it's not the same exact issue.

Still looking.

-ml

Re: Drop to ddb on boot with "cpu1 failed to become ready" on 5.8-stable i386 (VirtualBox 5.x-specific)

[Mike Larkin]

On Sat, Oct 10, 2015 at 08:56:03PM -0500, Brian Conway wrote:
> Preface: I believe this is a regression in VirtualBox 5.x and reported
> it to them a while ago (https://www.virtualbox.org/ticket/14515). I'm
> sending it along to bugs@ just in case the trace is of interest to
> anyone. If not, feel free to disregard.

Following up on old mails. From the link above it looks like this was
fixed by Virtualbox already.

-ml

> 
> Symptom: When booting 5.8-stable i386 with > 1 CPU, system halts on
> boot before /etc/rc with "cpu1 failed to become ready".
> 
> Workarounds:
> - Revert to VirtualBox 4.3.30.
> - Drop CPU count to 1.
> - Use 5.7-stable i386.
> - Use any version of amd64 with any number of CPUs.
> - Don't use VirtualBox.
> 
> Dmesg, trace, ps, registers below. Thanks for your time.
> 
> Brian Conway
> 
> >> OpenBSD/i386 BOOT 3.26
> boot>
> booting hd0a:/bsd: 9749372+1069036 [83+411760+405701]=0xb18eb8
> entry point at 0x200120
> 
> [ using 818000 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-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
> 
> OpenBSD 5.8-stable (GENERIC.MP) #0: Fri Oct  2 22:21:38 UTC 2015
> 
> r...@buildi386.int.rcesoftware.com:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz ("GenuineIntel"
> 686-class) 2.30 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,LONG,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,HV,LAHF,ITSC
> real mem  = 804732928 (767MB)
> avail mem = 776245248 (740MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfda00, 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)
> 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) i7-3615QM CPU @ 2.30GHz ("GenuineIntel"
> 686-class) 2.30 GHz
> cpu1: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,LONG,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,HV,LAHF,ITSC
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz ("GenuineIntel"
> 686-class) 2.30 GHz
> cpu2: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,LONG,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,RDRAND,HV,LAHF,ITSC
> ioapic0 at mainbus0: apid 3 pa 0xfec0, version 11, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpicpu2 at acpi0: C1(@1 halt!)
> acpibat0 at acpi0: BAT0 model "1" serial 0 type VBOX oem "innotek"
> acpiac0 at acpi0: AC unit online
> acpivideo0 at acpi0: GFX0
> bios0: ROM list: 0xc/0x8000 0xe2000/0xd000
> pvbus0 at mainbus0: KVM
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> 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)
> em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 3 int 19,
> address 08:00:27:c3:57:d8
> "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: SMBus 
> disabled
> ahci0 at pci0 dev 13 function 0 "Intel 82801HBM AHCI" rev 0x02: apic 3
> int 21, AHCI 1.1
> ahci0: device on port 0 didn't come ready, TFD: 0x171
> ahci0: port 0: 3.0Gb/s
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
> fixed t10.ATA_VBOX_HARDDISK_VBe5c20152-ef51bee2_
> sd0: 10240MB, 512 bytes/sector, 20971520 sectors
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on sd0a (1e7613432019dde1.a) swap on sd0b dump on sd0b
> cpu1 

Re: blank screen with LCD off after waking up from suspend

[Mike Larkin]

On Sat, Nov 21, 2015 at 01:29:18AM -0800, aaron.mille...@gmail.com wrote:
> >Synopsis:sometimes, waking up from suspend results in a black screen 
> >with the LCD turned off
> >Category:system kernel amd64
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8-current (GENERIC.MP) #1616: Sun Nov 15 
> 20:58:13 MST 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I had X with KDE running on my laptop, and I closed the lid, which
>   caused a suspend. When I opened the lid again sometime later, I didn't 
> see
>   anything on the screen, and the LCD backlight was turned off. Caps Lock 
> turned
>   on and off the indicator light, so the keyboard was working.
> 
>   The dmesg and usbdevs info in this bug report is from after I forced a 
> restart.
> >How-To-Repeat:
>   Unfortunately, I'm not sure how to replicate this. It doesn't happen 
> every time -- so far it's only happened once.
> >Fix:
>   I don't know how to fix it.
> 

Should this happen again, it may be sitting in ddb.

Try ssh'ing into the machine and if that works, do a dmesg remotely
and see if it gives any hints.

If ssh doesn't work. you can (blindly) try:

trace
boot reboot

("boot reboot" reboots the machine from ddb)

Then check if your dmesg survived across the reboot on the next boot.
Sometimes more than one "boot reboot" is needed (all typed blindiy).

-ml

> 
> dmesg:
> OpenBSD 5.8-current (GENERIC.MP) #1616: Sun Nov 15 20:58:13 MST 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8464150528 (8072MB)
> avail mem = 8203472896 (7823MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb270 (42 entries)
> bios0: vendor American Megatrends Inc. version "4.6.5" date 05/24/2012
> bios0: CLEVO CO. W240EU/W250EUQ/W270EUQ
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT
> acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
> USB6(S3) USB7(S3) PXSX(S5) RP01(S4) PXSX(S5) RP02(S4) PXSX(S5) RP03(S4) 
> PXSX(S5) RP04(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-3630QM CPU @ 2.40GHz, 2394.92 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> 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 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.57 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> 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-3630QM CPU @ 2.40GHz, 2394.57 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> 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-3630QM CPU @ 2.40GHz, 2394.57 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.57 MHz
> cpu4: 
> 

Re: x200s on lap, reboots

[Mike Larkin]

On Sun, Jan 10, 2016 at 06:27:05PM +0100, Marcus MERIGHI wrote:
> Nothing that I have done except having it on my lap, lid open. IIRC.
> I'm not even sure this is a bug, maybe some hardware failed or I might
> have bent it or pulled out the sd card.

softdep on umass is pretty risky.

-ml

> 
> dmesg with stack trace:
> 
> uvideo0 at uhub3 port 6 configuration 1 interface 0 "Lenovo product
> 0x480c" rev 2.00/31.34 addr 2
> video0 at uvideo0
> umass0 at uhub7 port 6 configuration 1 interface 0 "RICOH USB2.0-FLASH
> Media" rev 2.00/0.01 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> sd1 at scsibus2 targ 1 lun 0:  SCSI2
> 0/direct removable serial.05ca1880R5U880-3
> sd1: 1882MB, 512 bytes/sector, 3854336 sectors
> 
> panic: ehci_device_clear_toggle: queue active
> Starting stack trace...
> panic() at panic+0x10b
> ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
> umass_clear_endpoint_stall() at umass_clear_endpoint_stall+0x44
> usb_transfer_complete() at usb_transfer_complete+0x26c
> ehci_abort_xfer() at ehci_abort_xfer+0x2c7
> ehci_timeout_task() at ehci_timeout_task+0x2c
> usb_abort_task_thread() at usb_abort_task_thread+0x73
> end trace frame: 0x0, count: 250
> End of stack trace.
> syncing disks... done
> /: got error 6 while accessing filesystem
> panic: softdep_deallocate_dependencies: unrecovered I/O error
> Starting stack trace...
> panic() at panic+0x10b
> softdep_deallocate_dependencies() at
> softdep_deallocate_dependencies+0x4a
> brelse() at brelse+0x65
> sdstrategy() at sdstrategy+0x83
> spec_strategy() at spec_strategy+0x53
> VOP_STRATEGY() at VOP_STRATEGY+0x46
> bwrite() at bwrite+0xec
> VOP_BWRITE() at VOP_BWRITE+0x38
> ffs_fsync() at ffs_fsync+0x13f
> VOP_FSYNC() at VOP_FSYNC+0x3c
> ffs_flushfiles() at ffs_flushfiles+0xb9
> softdep_flushfiles() at softdep_flushfiles+0x3e
> ffs_unmount() at ffs_unmount+0x48
> dounmount() at dounmount+0x84
> vop_generic_revoke() at vop_generic_revoke+0x130
> VOP_REVOKE() at VOP_REVOKE+0x37
> vdevgone() at vdevgone+0x72
> disk_gone() at disk_gone+0x9c
> sddetach() at sddetach+0x35
> config_detach() at config_detach+0x13c
> scsi_detach_lun() at scsi_detach_lun+0x97
> sr_discipline_shutdown() at sr_discipline_shutdown+0x147
> sr_shutdown() at sr_shutdown+0x2a
> boot() at boot+0x144
> reboot() at reboot+0x26
> panic() at panic+0x106
> ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
> umass_clear_endpoint_stall() at umass_clear_endpoint_stall+0x44
> usb_transfer_complete() at usb_transfer_complete+0x26c
> ehci_abort_xfer() at ehci_abort_xfer+0x2c7
> ehci_timeout_task() at ehci_timeout_task+0x2c
> usb_abort_task_thread() at usb_abort_task_thread+0x73
> end trace frame: 0x0, count: 225
> End of stack trace.
> 
> dumping to dev 4,1 offset 1051485
> dump 3989 3988 3987 3986 3985 [...] 3 2 1 succeeded
> 
> rebooting...
> 
> OpenBSD 5.8-current (GENERIC.MP) #1757: Sat Dec 19 08:17:18 MST 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4166717440 (3973MB)
> avail mem = 4036304896 (3849MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
> bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
> bios0: LENOVO 7470W1W
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT
> TCPA DMAR SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4)
> EXP2(S4) EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(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)2 Duo CPU L9400 @ 1.86GHz, 1862.30 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 6MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
> cpu0: apic clock running at 265MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.00 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 6MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xe000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: 

Re: Macbook Pro acpi0 uses 100% CPU

[Mike Larkin]

On Mon, May 30, 2016 at 04:54:43PM +0200, Evgeniy Sudyr wrote:
> Unfortunately I was not able to sendbug directly from device because
> of no network connectivity on this host (yet).
> 

could be a stuck GPE, but without an acpidump, we'll never know.

Looks like the machine has (at least on the motherboard) a bge(4).

If that can't be used, copy the dump to a usb stick and send it from
another machine.

-ml

> I do have Apple MacBook Pro "Core i7" 2.3 15" Late 2013 ( A1398 and  EMC 2674)
> 
> http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-i7-2.3-15-iris-only-late-2013-retina-display-specs.html
> 
> I will be more than glad to test patch or provide more details.
> 
> Synopsis: ACPI makes 100% CPU load on one core
> Category: amd64
> Environment:
> System  : OpenBSD 6.0
> Details : OpenBSD 6.0-beta (GENERIC.MP) #2128: Thu May 26
> 23:46:33 MDT 2016
> 
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> Architecture: OpenBSD.amd64
> Machine : amd64
> Description:
> How-To-Repeat: Check CPU usage with top
> 
> Load averages:  1.19,  0.98,  0.54localhost.eject.name 20:46:27
> 57 processes: 1 running, 48 idle, 8 on processor  up  0:08
> CPU0 states:  0.0% user,  0.0% nice, 73.7% system, 12.7% interrupt, 13.6% idle
> CPU1 states:  0.1% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
> CPU2 states:  0.2% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.1% idle
> CPU3 states:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9% idle
> CPU4 states:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9% idle
> CPU5 states:  0.0% user,  0.0% nice,  0.3% system,  0.0% interrupt, 99.7% idle
> CPU6 states:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9% idle
> CPU7 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> 
> Memory: Real: 40M/184M act/tot Free: 15G Cache: 50M Swap: 0K/0K
>  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> 29438 root -2200K   18M onproc- 8:02 100.00% idle3
>  7155 root -2200K   18M onproc- 8:02 100.00% idle4
> 53203 root -2200K   18M onproc- 7:35 100.00% idle7
> 80448 root -2200K   18M sleep - 8:02 99.32% idle5
> 46368 root -2200K   18M onproc- 7:35 99.02% idle6
> 60590 root  1000K   18M onproc- 6:03 74.22% acpi0
> 34781 root -2200K   18M onproc- 7:58  0.00% idle1
> 59356 root -2200K   18M onproc- 7:58  0.00% idle2
> 97100 root -2200K   18M idle  - 1:54  0.00% idle0
> 17465 _smtpd 20 1500K 3588K idle  kqread0:05  0.00% smtpd
> 68834 _smtpd 20 1452K 3452K idle  kqread0:05  0.00% smtpd
> 75138 _x11   20   14M   20M idle  select0:04  0.00% Xorg
> 50773 root  1000K   18M sleep bored 0:02  0.00% systq
> 31028 root  1000K   18M sleep bored 0:02  0.00% sensors
> 69542 root  1000K   18M idle  usbtsk0:01  0.00% usbtask
> 0 root -1800K   18M sleep schedul   0:01  0.00% swapper
> 83499 root  1000K   18M sleep pftm  0:01  0.00% pfpurge
> 30351 root  1000K   18M sleep bored 0:01  0.00% systqmp
> 
> dmesg:
> OpenBSD 6.0-beta (GENERIC.MP) #2128: Thu May 26 23:46:33 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error
> ff
> real mem = 17065656320 (16275MB)
> avail mem = 16543842304 (15777MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x7ad14000 (45 entries)
> bios0: vendor Apple Inc. version "MBP112.88Z.0138.B17.1602221600" date
> 02/22/2016
> bios0: Apple Inc. MacBookPro11,2
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT
> SSDT SSDT SSDT MCFG DMAR
> acpi0: wakeup devices P0P2(S3) PEG1(S3) EC__(S3) GMUX(S3) HDEF(S3)
> RP03(S4) ARPT(S4) RP04(S4) RP05(S3) XHC1(S3) ADP1(S3) LID0(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz, 2993.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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 

Re: installer amd64 'Get/Verify bsd' -> 'Illegal instruction' - shuttle ds47d

[Mike Larkin]

On Wed, Jan 27, 2016 at 06:08:49PM +0100, Marcus MERIGHI wrote:
> Regression: from 5.8 onwards install fails on three of these shuttle
> ds47d machines (5.7 works, 5.8 and -current doesn't). 
> 
> They are supposed to be identical, two bought at once, one a little
> earlier.
> 
> How it fails: 'Get/Verify SHA256.sig' succeeds, but 'Get/Verify bsd'
> stopps instantly and gives only 'Illegal instruction'.

There seem to be a few instances of this happening recently, given 
various threads on misc/tech/bugs@. IIRC someone traced the instruction
to a syscall (maybe it was sysret, can't recall) by dumping one of the
binaries that was having problems, but nobody could explain why that was
occurring since if that were really an invalid instruction, it would have
failed on the first use, not some thousand or so calls later.

Both of those instructions can indeed generate #UD, but apparently only
if you either aren't in 64 bit mode (not the case) or if EFER gets trashed
(likely not the case either). So, I'm stumped.

I don't have any other advice at the moment, but am replying here to
keep the thread up to date with what I recall being the most up to date
info.

-ml

> 
> I've done installs of 5.7, 5.8 and -current multiple times on all three
> of these machines. I've swapped RAM with my notebook. I took everything
> out that can be removed (mSATA SSD, wlan). I do not think this is a 
> hardware or user failure (anymore).
> 
> What I've found out: 
> I can run -current, when booting from externally installed usb stick: 
> sshd(8) stops when the first client disconnects. 
> cron(8) stops when it sends an email.
> top(1) returns normally on 'q', prints 'Illegal instruction' on strg+c.
> ping(8) returns 'Illegal instruction' after printing the first line.
> 
> Testing the commands that are run by install.sub on the running -current
> system shows, that if I ftp to file and run the file through sha256
> there is no problem. The pipe is causing the 'Illegal instruction'.
> 
> I tried my gdb voodoo but it is weak...
> gdb(1) 'bt' on the cores has one thing in common:  - no such
> file.
> 
> Below my posts to misc@ (sorry!), followed by -current (24/1) dmesg.
> 
> Attached is the usual info on bugs@, for 5.7 and -current (24/1). 
> 
> One of the machines is ready for debugging. Please advise!
> 
> Bye + Thanks for reading, Marcus
> 
> mcmer-open...@tor.at (Marcus MERIGHI), 2016.01.22 (Fri) 16:14 (CET):
> > please disregard!
> > 
> > sorry, right after hitting send I realized that this was not a -current
> > install as usual but a 5.8 one. 
> > 
> > Therefore I'm quite sure the problem is hardware/PEBKAC. 
>  
> > mcmer-open...@tor.at (Marcus MERIGHI), 2016.01.22 (Fri) 16:11 (CET):
> > > I just downloaded amd64 bsd.rd, put it on an usb stick, booted a new
> > > machine from usb.
> > > 
> > > When the file sets were selected, 'Get/Verify SHA256.sig' succeeded, but
> > > 'Get/Verify bsd' stopped instantly and gave only 'Illegal instruction'. 
> > > 
> > > Before this the only thing that didn't work was fetching the mirror
> > > list. I entered one manually and the installer proceeded.
> > > 
> > > The machine once had OpenBSD loaded and worked, it's a Shuttle DS47,
> > > dmesg is in the archives. 
> > > 
> > > The USB drive I used is the one I always use for these tasks.
> 
> OpenBSD 5.9-beta (RAMDISK_CD) #1695: Sun Jan 24 21:40:49 MST 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 4161052672 (3968MB)
> avail mem = 4033228800 (3846MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
> bios0: vendor American Megatrends Inc. version "1.03" date 08/09/2013
> bios0: Shuttle Inc. DS47D
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP APIC FPDT MCFG SLIC HPET SSDT SSDT SSDT
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) CPU 847 @ 1.10GHz, 1097.70 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (P0P1)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus 2 (RP02)
> acpiprt4 at acpi0: bus 3 (RP03)
> acpiprt5 at acpi0: bus 4 (RP04)
> acpiprt6 at acpi0: bus -1 (RP05)
> acpiprt7 at acpi0: bus -1 (RP06)
> acpiprt8 at acpi0: bus -1 (RP07)
> acpiprt9 at acpi0: bus -1 (RP08)
> acpiprt10 at acpi0: bus -1 (PEG0)
> acpiprt11 at acpi0: bus -1 (PEG1)
> acpiprt12 at acpi0: bus -1 (PEG2)
> acpiprt13 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: not present
> acpicpu at acpi0 

Re: Asus-K75D Notebook: acpi0/acpitz0 causing crashes in OpenBSD 5.6 or newer.

[Mike Larkin]

On Tue, Mar 08, 2016 at 11:32:02PM -0800, Philip Guenther wrote:
> On Tue, 8 Mar 2016, Rickster wrote:
> > acpidump:
> ...
> 
> Looks like another HW-reduced ACPI platform issue.  From the decompiled 
> acpidump, the EC device definition includes:
> 
> Scope (_SB.PCI0.SBRG)
> {   
> Device (EC0)
> {   
> Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)  
> //
>  _HID: Hardware ID
> Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource 
> Settings
> {
> IO (Decode16,
> 0x0062, // Range Minimum
> 0x0062, // Range Maximum
> 0x00,   // Alignment
> 0x01,   // Length
> )
> IO (Decode16,
> 0x0066, // Range Minimum
> 0x0066, // Range Maximum
> 0x00,   // Alignment
> 0x01,   // Length
> )
> Memory32Fixed (ReadWrite,
> 0xFF00, // Address Base
> 0x1000, // Address Length
> )
> })
> Name (_GPE, 0x03)  // _GPE: General Purpose Events
> ...
> 
> 
> We only accept 2 registers in the EC _CRS, but ACPI 5.0 spec section 
> 12.11's Table 12-260 "Embedded Controller Device Object Control Methods" 
> says this about the EC _CRS:
> 
> The first address region returned is the data port, and the second 
> address region returned is the status/command port for the 
> embedded controller. If the EC is used on a HW-Reduced ACPI 
> platform, a third resource is required, which is the GPIO 
> Interrupt Connection resource for the EC's SCI Interrupt.
> 
> I guess acpiec.c's sci handling will need to be taught how to use that 3rd 
> register for this hardware to be supported...
> 
> 
> Philip Guenther
> 

Nice find. I didn't notice that. I agree with your assessment.

-ml

Re: Asus-K75D Notebook: acpi0/acpitz0 causing crashes in OpenBSD 5.6 or newer.

[Mike Larkin]

On Wed, Mar 09, 2016 at 01:32:29AM -0500, Rickster wrote:
> To: bugs@openbsd.org
> Subject:
> From: bsdsola...@gmail.com
> Cc: root
> Reply-To:bsdsola...@gmail.com
> 
> >Synopsis: 5.6, or newer releases.>
> >Category:
> >Environment:
> System  : OpenBSD 5.5
> Details : OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST
> 2014
>  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> 
> >How-To-Repeat:
> 
> >Fix:
> 
> 
> SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached.
> SENDBUG: Feel free to delete or use the -D flag if they contain sensitive
> information.

I changed acpitz(4) around this time to work around broken thermal zones
that always reported 0 degC / 255 degC. It looks like yours is even
more broken, or (more likely) the failure to initialize acpiec is causing
another failure.

Can you build with ACPI_DEBUG on -current and capture the dmesg to see where
it's failing to initialize acpiec(4)? (also set acpi_debug to a reasonable
value so you see debugging output).

Thanks.

-ml

> 
> dmesg:
> OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 7980703744 (7610MB)
> avail mem = 7759646720 (7400MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb4c0 (49 entries)
> bios0: vendor American Megatrends Inc. version "217" date 10/23/2014
> bios0: ASUSTeK COMPUTER INC. K75DE
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG MSDM HPET SSDT SSDT CRAT
> acpi0: wakeup devices SBAZ(S4) OHC1(S3) EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3)
> EHC3(S3) OHC4(S3) XHC0(S3) XHC1(S3) PE20(S4) PE21(S4) PE22(S4) PE23(S4)
> LOM_(S4) P0PC(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 16 (boot processor)
> cpu0: AMD A10-4600M APU with Radeon(tm) HD Graphics , 2296.28 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,ITSC,BMI1
> cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
> 64b/line 16-way L2 cache
> cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully
> associative
> cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully
> associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
> cpu1 at mainbus0: apid 17 (application processor)
> cpu1: AMD A10-4600M APU with Radeon(tm) HD Graphics , 2295.71 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,ITSC,BMI1
> cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
> 64b/line 16-way L2 cache
> cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully
> associative
> cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully
> associative
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 18 (application processor)
> cpu2: AMD A10-4600M APU with Radeon(tm) HD Graphics , 2295.71 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,ITSC,BMI1
> cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
> 64b/line 16-way L2 cache
> cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully
> associative
> cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully
> associative
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 19 (application processor)
> cpu3: AMD A10-4600M APU with Radeon(tm) HD Graphics , 2295.71 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,ITSC,BMI1
> cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
> 64b/line 16-way L2 cache
> cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully
> associative
> cpu3: DTLB 64 4KB entries fully associative, 64 

Re: Potential MP problem in OpenBSD 5.8

[Mike Larkin]

On Sun, Mar 06, 2016 at 04:33:59PM +0100, Mischa wrote:
> Hi,
> 
> Reyk asked me to post the following panics on this list.
> I have seen multiple panics when running the stock relayd / httpd on both 
> bhyve and bare metal.
> Here are the 2 I captured.
> 
> The first trace is from OpenBSD 5.8 running on bhyve (FreeBSD 10.2).
> 
>  https://gist.github.com/mischapeters/11dd221087c2b04b7741
> panic: mtx_enter: locking against myself
> Stopped at  0x8133fc09: leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb>
> ddb> trace
> (null)() at 0x8133fc09
> (null)() at 0x811a310e
> (null)() at 0x8132508f
> (null)() at 0x811bc830
> (null)() at 0x8123f060
> (null)() at 0x81253abd
> (null)() at 0x81254900
> (null)() at 0x81193a95
> (null)() at 0x81324632
> (null)() at 0x8133b3cf
> (null)() at 0x8119f8f5
> (null)() at 0x811bb0f6
> (null)() at 0x811bb6bc
> (null)() at 0x811bee6e
> (null)() at 0x813233ae

Please tell bhyve to implement proper elf symbol loading in their bootloader.
The trace above is pretty useless.

-ml

Re: resume fails on -current #2000 on lenovo x200s

[Mike Larkin]

On Tue, May 03, 2016 at 03:59:33PM +0800, Ray Lai wrote:
> This commit broke resume on my x200:
> 
> https://marc.info/?l=openbsd-cvs=146194866402207=2
> 
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2016/04/29 10:49:53
> > 
> > Modified files:
> > sys/arch/amd64/amd64: cpu.c 
> > sys/arch/i386/i386: cpu.c 
> > sys/arch/sparc64/sparc64: cpu.c 
> > 
> > Log message:
> > Call sched_init_cpu() just before booting secondary CPUs.
> > 
> > This prevent the scheduler from scheduling tasks to CPUs not beeing able
> > to execute them during the boot process.
> > 
> > ok visa@, kettenis@
> 

Thank you for identifying the commit. As subsequently reported,
kettenis has temporarily reverted this until we can find a better way.

-ml

> dmesg:
> OpenBSD 5.9-current (GENERIC.MP) #21: Tue May  3 15:35:09 HKT 2016
> r...@x.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4166717440 (3973MB)
> avail mem = 4035948544 (3848MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (62 entries)
> bios0: vendor LENOVO version "6DET28WW (1.05 )" date 07/30/2008
> bios0: LENOVO 766313U
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA 
> DMAR SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
> EXP3(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EHC0(S3) 
> EHC1(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)2 Duo CPU P8600 @ 2.40GHz, 2394.36 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 3MB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
> cpu0: apic clock running at 265MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.00 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 3MB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xe000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus -1 (EXP2)
> acpiprt5 at acpi0: bus 5 (EXP3)
> acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 104 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> "PNP0303" at acpi0 not configured
> "IBM3780" at acpi0 not configured
> "INTC0102" at acpi0 not configured
> acpibat0 at acpi0: BAT0 model "42T4647" serial  1666 type LION oem "SANYO"
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> "PNP0C14" at acpi0 not configured
> acpidock0 at acpi0: GDCK not docked (0)
> acpivideo0 at acpi0: VID_
> acpivout0 at acpivideo0: LCD0
> acpivideo1 at acpi0: VID_
> cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2401, 2400, 1600, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
> inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: msi
> inteldrm0: 1280x800
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
> "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
> em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
> 00:1f:16:39:31:3e
> uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
> uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
> uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
> ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "Intel EHCI root hub" rev 

Re: resume fails on -current #2000 on lenovo x200s

[Mike Larkin]

On Mon, May 02, 2016 at 12:28:49PM +0200, Marcus MERIGHI wrote:
> mlar...@azathoth.net (Mike Larkin), 2016.04.30 (Sat) 12:42 (CEST):
> > On Sat, Apr 30, 2016 at 10:38:08AM +0200, Marcus MERIGHI wrote:
> > > >Synopsis:resume fails on -current #2000 on lenovo x200s 
> > > >Category:suspend/resume
> > > >Environment:
> > >   System  : OpenBSD 5.9
> > >   Details : OpenBSD 5.9-current (GENERIC.MP) #2000: Fri Apr 29 
> > > 17:01:24 MDT 2016
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > >   Architecture: OpenBSD.amd64
> > >   Machine : amd64
> > > >Description:
> > >   Suspending works, resume does not. The half-moon LED keeps blinking. 
> > >   Sometimes I can hear the fans spin up. 
> > > This is a regression, resume stil worked with the snapshot #1983
> > > Mon Apr  4 21:50:41 MDT 2016
> > > >How-To-Repeat:
> > >   On a lenovo X200s run OpenBSD 5.9-current #2000.
> > >   Suspend via Fn+F4 or zzz(8); open lid or press Fn to initiate resume.
> > > >Fix:
> > >   None known to me apart from pressing the power button > 5s.
> > 
> > Start bisecting diffs as this is a small window of time. Let us know
> > when you have identified the offending commit as not many of us have
> > an x200s.
> 
> With GENERIC, btw, suspend/resume works. 
> 
> I've tried the following (without results):
> 
> Searched tech@ for the string 'resume' via marc.info. Obvious hit:
> 'Keyboard resume (zzz) diff' [0]. I Updated my local sources to
> -current, removed the code additions by mlarkin@ in pckbd.c, compiled
> kernel, booted it; resume does not work with GENERIC.MP
> 
> Then I searched src/sys for 'resume' (no hit) and 'suspend'. The file
> 'dev/pci/drm/i915/i915_suspend.c' hasn't been touched since 2015/09/23,
> though. 
> 
> Then, in src/sys/dev I did 'cvs -q log -N -d"2016-04-01<2016-04-29"'.
> This got me a long list that I searched for "suspend" and "resume" with 
> no new result. Then I searched for "revision " and checked every commit
> of April for anything that might affect me. I found none that I could
> make sense of wrt my resume problem. 
> 
> Any pointers? Where to look next? 
> 

Bisect diffs like I suggested originally. What you are trying to do
is cherry pick what you think might be the problem. The commit causing the issue
could be completely unrelated and likely doesn't have 'suspend' or 'resume'
in the comment.

Check out an entire sys/ from, say Apr 15 (which is about halfway between Apr 4
when it "last worked", and when you reported it. If that works, move up to
Apr 22, if not, back off to something before. Rinse, repeat.

You will eventually narrow it down to the diff that fails. When you find it,
let us know. 1 month of diffs is not hard to do.

-ml

> [0] http://marc.info/?l=openbsd-tech=146035659601245
> 
> > > dmesg:
> > > OpenBSD 5.9-current (GENERIC.MP) #2000: Fri Apr 29 17:01:24 MDT 2016
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > real mem = 4166717440 (3973MB)
> > > avail mem = 4035842048 (3848MB)
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
> > > bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
> > > bios0: LENOVO 7470W1W
> > > acpi0 at bios0: rev 2
> > > acpi0: sleep states S0 S3 S4 S5
> > > acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA 
> > > DMAR SSDT SSDT SSDT
> > > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
> > > EXP2(S4) EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(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)2 Duo CPU L9400 @ 1.86GHz, 1862.25 MHz
> > > cpu0: 
> > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> > > cpu0: 6MB 64b/line 16-way L2 cache
> > > cpu0: smt 0, core 0, package 0
> > > mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
> > > cpu0: apic clock running at 266MHz
> > > cpu0: mwait 

Re: Virtualized OpenBSD under FreeBSD/bhyve and PCI Passthrough fails

[Mike Larkin]

On Fri, Aug 12, 2016 at 05:01:32AM +0200, borisbo...@gmx.net wrote:
> >Synopsis:Virtualized OpenBSD under FreeBSD/bhyve and PCI passthrough 
> >fails with interrupt errors
> >Category:system
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   A virtualized OpenBSD under FreeBSD 11-beta4 and bhyve doesn't accept 
> any PCI devices via PCI passthrough (which are having MSI-(x) interrupts of 
> course) and giving following errors:
> 
> Aug 12 02:31:20 aphrodite /bsd: em0 at pci0 dev 5 function 0 "Intel I217-V" 
> rev 0x00pci_intr_map: bad interrupt line 20
> Aug 12 03:44:15 aphrodite /bsd: re0 at pci0 dev 5 function 0 "Realtek 8168" 
> rev 0x0cpci_intr_map: bad interrupt line 19
> 
> The CPU is a broadwell one: CPU: Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz 
> (2893.36-MHz K8-class CPU)
> 
> The same problem occurs on a broadwell CPU with a late 2014 Mac Mini. All 
> other OS(es) (FreeBSD/Linux) don't have the issue as guest. I also added the 
> Issue under: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205445 
> (comment 4).
> 
> That configuration should work at least under possibly another CPU 
> configuration: https://forums.freebsd.org/threads/50470/
> 
> So, I'm not sure, on which parts (bhyve/passthrough or OpenBSD) the problem 
> is... so I adress it here, too. I also tried it on an actual Todays 
> 6.0-snapshot. The same errors occurs.
> 
> >How-To-Repeat:
>   See above.
> >Fix:
>   Don't use PCI passthrough and just use NICs without IP under FreeBSD 
> under Bridge mode.
> 

Can you please give us the output of pcidump -xxv when it fails? The pcidump
below seems to be from a boot where you weren't using pci passthrough on the
host and thus does not include the relevant PCI config space data for the
passed-through em/re.

-ml

> 
> dmesg:
> OpenBSD 5.9 (GENERIC) #1761: Fri Feb 26 01:15:04 MST 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 1056964608 (1008MB)
> avail mem = 1021227008 (973MB)
> warning: no entropy supplied by boot loader
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (9 entries)
> bios0: vendor BHYVE version "1.00" date 03/14/2014
> acpi0 at bios0: rev 2
> acpi0: sleep states S5
> acpi0: tables DSDT APIC FACP HPET MCFG
> 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-4570S CPU @ 2.90GHz, 2893.38 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
> 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 134MHz
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpihpet0 at acpi0: 1000 Hz
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PC00)
> pvbus0 at mainbus0: bhyve
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 unknown vendor 0x1275 product 0x1275 rev 0x00
> virtio0 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio0
> scsibus1 at vioblk0: 2 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 40960MB, 512 bytes/sector, 83886080 sectors
> virtio0: apic 0 int 16
> virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio1: address 58:9c:fc:0e:54:a8
> virtio1: apic 0 int 17
> pcib0 at pci0 dev 31 function 0 "Intel 82371SB ISA" rev 0x00
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0 mux 1
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> /dev/ksyms: Symbol table not valid.
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on sd0a (6f79402a9067a2c7.a) swap on sd0b dump on sd0b
> 
> usbdevs:
> usbdevs: no USB controllers found
> 
> pcidump:
> Domain /dev/pci0:
>  0:0:0: unknown unknown
>   0x: Vendor ID: 1275 Product ID: 1275
>   0x0004: Command: 0007 Status: 0010
>   0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00
>   0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
>   0x0010: BAR empty ()
>   0x0014: BAR empty ()
>   

Re: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot

[Mike Larkin]

On Mon, Jul 11, 2016 at 10:37:23PM +0200, stolendata.net wrote:
> Apologies if this is not the preferred mailing list for this.
> 
> As I can't get the machine to boot, I'll just provide a picture of the
> crash: http://i.imgur.com/KDcPwTg.jpg

Looks like this is crashing in pool_p_alloc, but not sure why yet.

> 
> With 5.9/AMD64-release the kernel manages to get just a few steps further,
> crashing after a few lines of the "BIOS0" enumeration. If a picture of this
> would help let me know and I'll fire the machine up again. I've tried

This would be nice, if you could. It would indicate if i386 and amd64 are
failing at the same place.

-ml

> fiddling around with various CPU- and on-board features in the BIOS to no
> avail, no change in behavior.
> 
> The board is an MSI K9N6SGM-V (nForce 430/MCP61). It has the latest
> available BIOS flashed, and memory + SATA drive is working just fine - the
> machine has been running Arch Linux for the past two years without any
> problems.

Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot

[Mike Larkin]

On Tue, Jul 12, 2016 at 12:09:03AM +0200, stolendata.net wrote:
> GENERIC.MP AMD64/5.9-release booted from full install on USB disk behaves
> the exact same way as the ramdisk kernel, stops booting at the same point.
> Do you want me to try a full i386 install as well?
> 

Please, since at least i386 panics. You might get into ddb and can do a
backtrace.

-ml

> On Mon, Jul 11, 2016 at 11:41 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > On Mon, Jul 11, 2016 at 11:36:22PM +0200, stolendata.net wrote:
> >
> > >
> > > If it's of any value to help narrow the problem down, this particular CPU
> > > model is probably not the culprit. I've been running OpenBSD on one on
> > > another board since 4.9.
> > >
> >
> > Even though you don't have a full install, can you try booting a regular
> > non-ramdisk kernel instead? The ramdisk kernel has a bunch of stuff
> > stripped
> > out (including ddb), and trying a regular kernel may give us more data
> > points.
> > Of course, it won't boot since you don't have a full install, but if it
> > gets
> > that far, that's information as well.
> >
> > This can be done in a variety of ways, including using another machine and
> > installing to a USB stick.
> >
> > -ml
> >
> > >
> > > On Mon, Jul 11, 2016 at 11:05 PM, Mike Larkin <mlar...@azathoth.net>
> > wrote:
> > >
> > > > On Mon, Jul 11, 2016 at 10:37:23PM +0200, stolendata.net wrote:
> > > >
> > > > > With 5.9/AMD64-release the kernel manages to get just a few steps
> > > > further,
> > > > > crashing after a few lines of the "BIOS0" enumeration. If a picture
> > of
> > > > this
> > > > > would help let me know and I'll fire the machine up again. I've tried
> > > >
> > > > This would be nice, if you could. It would indicate if i386 and amd64
> > are
> > > > failing at the same place.
> > > >
> > > > -ml
> > > >
> > > >
> >

Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot

[Mike Larkin]

On Tue, Jul 12, 2016 at 12:30:23AM +0200, stolendata.net wrote:
> Alright, ddb prompt pops up on i386. Last output from kernel:
> 
> real mem ...
> avail mem ...
> kernel: page fault trap, code=0
> Stopped at  memcpy+0x13:repe movsl(%esi),%es:(%edi)

in ddb:
trace

ps

take some pictures and send some links.


> 
> If there's any chance you think you can guide me through pulling some
> valuable info from here and on, I'm game.
> 
> 
> On Tue, Jul 12, 2016 at 12:12 AM, Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > On Tue, Jul 12, 2016 at 12:09:03AM +0200, stolendata.net wrote:
> > > GENERIC.MP AMD64/5.9-release booted from full install on USB disk
> > behaves
> > > the exact same way as the ramdisk kernel, stops booting at the same
> > point.
> > > Do you want me to try a full i386 install as well?
> > >
> >
> > Please, since at least i386 panics. You might get into ddb and can do a
> > backtrace.
> >
> > -ml
> >
> > > On Mon, Jul 11, 2016 at 11:41 PM, Mike Larkin <mlar...@azathoth.net>
> > wrote:
> > >
> > > > On Mon, Jul 11, 2016 at 11:36:22PM +0200, stolendata.net wrote:
> > > >
> > > > >
> > > > > If it's of any value to help narrow the problem down, this
> > particular CPU
> > > > > model is probably not the culprit. I've been running OpenBSD on one
> > on
> > > > > another board since 4.9.
> > > > >
> > > >
> > > > Even though you don't have a full install, can you try booting a
> > regular
> > > > non-ramdisk kernel instead? The ramdisk kernel has a bunch of stuff
> > > > stripped
> > > > out (including ddb), and trying a regular kernel may give us more data
> > > > points.
> > > > Of course, it won't boot since you don't have a full install, but if it
> > > > gets
> > > > that far, that's information as well.
> > > >
> > > > This can be done in a variety of ways, including using another machine
> > and
> > > > installing to a USB stick.
> > > >
> > > > -ml
> > > >
> >

Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot

[Mike Larkin]

On Tue, Jul 12, 2016 at 01:28:21AM +0200, stolendata.net wrote:
> I just managed to get it to boot. The machine is running sort of headless
> with only the on-board IGP available, using 32MB of shared memory. I
> stepped this setting up in the BIOS to give the IGP 64MB of RAM and i386
> now boots, both the full install as well as the ramdisk kernel.
> 
> If it's of any value, dmesg.boot: http://pastebin.com/raw/ww0ezzed
> And sensors: http://pastebin.com/raw/ZZSNk6mG
> 
> Pardon the ANSI codes or whatever the garbage in the dmesg output is. I've
> no idea why that shows up in 5.9.

Can you show the output of "machine memory" at the boot> prompt?

I'm wondering if this machine has an odd memory layout.

(The trash in dmesg was just scribbled memory from a previous boot, linux
from the looks of it)

-ml

> 
> (I'm mailing these to dmesg@... as well)
> 
> 
> On Tue, Jul 12, 2016 at 12:32 AM, Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > On Tue, Jul 12, 2016 at 12:30:23AM +0200, stolendata.net wrote:
> > > Alright, ddb prompt pops up on i386. Last output from kernel:
> > >
> > > real mem ...
> > > avail mem ...
> > > kernel: page fault trap, code=0
> > > Stopped at  memcpy+0x13:repe movsl(%esi),%es:(%edi)
> >
> > in ddb:
> > trace
> >
> > ps
> >
> > take some pictures and send some links.
> >
> >
> > >
> > > If there's any chance you think you can guide me through pulling some
> > > valuable info from here and on, I'm game.
> > >
> > >
> >

Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot

[Mike Larkin]

On Mon, Jul 11, 2016 at 04:36:44PM -0700, Mike Larkin wrote:
> On Tue, Jul 12, 2016 at 01:28:21AM +0200, stolendata.net wrote:
> > I just managed to get it to boot. The machine is running sort of headless
> > with only the on-board IGP available, using 32MB of shared memory. I
> > stepped this setting up in the BIOS to give the IGP 64MB of RAM and i386
> > now boots, both the full install as well as the ramdisk kernel.
> > 
> > If it's of any value, dmesg.boot: http://pastebin.com/raw/ww0ezzed
> > And sensors: http://pastebin.com/raw/ZZSNk6mG
> > 
> > Pardon the ANSI codes or whatever the garbage in the dmesg output is. I've
> > no idea why that shows up in 5.9.
> 
> Can you show the output of "machine memory" at the boot> prompt?

 ... for both IGP settings, please.

-ml

> 
> I'm wondering if this machine has an odd memory layout.
> 
> (The trash in dmesg was just scribbled memory from a previous boot, linux
> from the looks of it)
> 
> -ml
> 
> > 
> > (I'm mailing these to dmesg@... as well)
> > 
> > 
> > On Tue, Jul 12, 2016 at 12:32 AM, Mike Larkin <mlar...@azathoth.net> wrote:
> > 
> > > On Tue, Jul 12, 2016 at 12:30:23AM +0200, stolendata.net wrote:
> > > > Alright, ddb prompt pops up on i386. Last output from kernel:
> > > >
> > > > real mem ...
> > > > avail mem ...
> > > > kernel: page fault trap, code=0
> > > > Stopped at  memcpy+0x13:repe movsl(%esi),%es:(%edi)
> > >
> > > in ddb:
> > > trace
> > >
> > > ps
> > >
> > > take some pictures and send some links.
> > >
> > >
> > > >
> > > > If there's any chance you think you can guide me through pulling some
> > > > valuable info from here and on, I'm game.
> > > >
> > > >
> > >
> 

Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot

[Mike Larkin]

On Mon, Jul 11, 2016 at 11:36:22PM +0200, stolendata.net wrote:
> http://i.imgur.com/2G0LRZj.jpg
> 
> At this point the boot stops progressing and the machine idles indefinitely
> with cursor blinking. Keyboard input has no effect.

Oh. I thought it paniced, like i386.

> 
> If it's of any value to help narrow the problem down, this particular CPU
> model is probably not the culprit. I've been running OpenBSD on one on
> another board since 4.9.
> 

Even though you don't have a full install, can you try booting a regular 
non-ramdisk kernel instead? The ramdisk kernel has a bunch of stuff stripped
out (including ddb), and trying a regular kernel may give us more data points.
Of course, it won't boot since you don't have a full install, but if it gets
that far, that's information as well.

This can be done in a variety of ways, including using another machine and
installing to a USB stick.

-ml

> 
> On Mon, Jul 11, 2016 at 11:05 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> 
> > On Mon, Jul 11, 2016 at 10:37:23PM +0200, stolendata.net wrote:
> >
> > > With 5.9/AMD64-release the kernel manages to get just a few steps
> > further,
> > > crashing after a few lines of the "BIOS0" enumeration. If a picture of
> > this
> > > would help let me know and I'll fire the machine up again. I've tried
> >
> > This would be nice, if you could. It would indicate if i386 and amd64 are
> > failing at the same place.
> >
> > -ml
> >
> >

Re: panic: BUG at /usr/src/sys/dev/pci/drm/drm_crtc.c:492

[Mike Larkin]

On Sun, Jul 10, 2016 at 08:19:12PM +0200, Matej Nanut wrote:
> >Synopsis:  panic: BUG at /usr/src/sys/dev/pci/drm/drm_crtc.c:492
> >Category:  kernel amd64
> >Environment:
> System  : OpenBSD 6.0
> Details : OpenBSD 6.0-beta (compile) #0: Wed Jul  6
> 21:31:48 CEST 2016
>  matej@puffy:/home/matej/openbsd/compile
>  (GENERIC.MP with options FONT_BOLD8x16,
>  XHCI_DEBUG and UMASS_DEBUG.)

-snip-

> 
> dmesg:
> OpenBSD 6.0-beta (compile) #0: Wed Jul  6 21:31:48 CEST 2016
> matej@puffy:/home/matej/openbsd/compile

Don't expect a lot of help when using a nonstandard kernel.

-ml

> real mem = 8479825920 (8086MB)
> avail mem = 8218279936 (7837MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebc30 (100 entries)
> bios0: vendor American Megatrends Inc. version "K53SV.320" date 11/11/2011
> bios0: ASUSTeK Computer Inc. K53SV
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET ECDT MCFG SSDT SSDT SSDT
> acpi0: wakeup devices P0P1(S4) EHC1(S3) USB1(S3) USB2(S3) USB3(S3)
> USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) PXSX(S4)
> PXSX(S4) PXSX(S4) PXSX(S4) PXSX(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-2670QM CPU @ 2.20GHz, 2195.35 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> 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 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2195.02 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> 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-2670QM CPU @ 2.20GHz, 2195.02 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> 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-2670QM CPU @ 2.20GHz, 2195.02 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2195.02 MHz
> cpu4: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 1, core 0, package 0
> cpu5 at mainbus0: apid 3 (application processor)
> cpu5: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2195.02 MHz
> cpu5: 
> 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu5: 256KB 64b/line 8-way L2 cache
> cpu5: smt 1, core 1, package 0
> cpu6 at mainbus0: apid 5 (application processor)
> cpu6: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2195.02 MHz
> cpu6: 
> 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu6: 256KB 64b/line 8-way L2 cache
> cpu6: smt 1, core 2, package 0
> cpu7 at mainbus0: apid 7 (application processor)
> cpu7: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2195.02 MHz
> cpu7: 
> 

Re: X crashes after resume from suspend, keyboard is unusable afterwards

[Mike Larkin]

On Sun, Jan 15, 2017 at 10:25:27AM +0100, Nils Reusse wrote:
> >Synopsis:X crashes after resume from suspend, keyboard is unusable 
> >afterwards
> >Category:system
> >Environment:
>   System  : OpenBSD 6.0
>   Details : OpenBSD 6.0-current (GENERIC.MP) #137: Fri Jan 13 
> 21:37:22 MST 2017
>
> bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   Resuming from suspend on the latest -current snapshot crashes X and

When did it break? Can you help us by narrowing it down a bit?

-ml

Re: Boot fails on i386 -current

[Mike Larkin]

On Fri, Sep 02, 2016 at 04:14:27PM +0200, Eivind Eide wrote:
> Boot fails on i386 -current
> 
> With last two snapshots the i386 bsd kernel fails to boot on this old
> machine I got.
> This is how boot attempts end (written down by hand)
> 
> (...snip...)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PCIE)
> acpiprt3 at acpi0: bus -1 (MPCI)
> acpicpu0 at acpi0unable to find cpu 0
> uvm_fault(0xd0baa160, 0x0, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped atacpicpu_getcst_from_fadt+0x37:  movlclean_idt+0x2f4(%eax),%
> eax
> ddb>
> 

Please use sendbug from a working machine so we get the aml.

-ml

> This is dmesg from somewhat older backup kernel I can still boot from:
> 
> OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz ("GenuineIntel"
> 686-class) 1.80 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PERF
> real mem  = 2146852864 (2047MB)
> avail mem = 2093072384 (1996MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 05/15/03, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev.
> 2.3 @ 0xf7690 (61 entries)
> bios0: vendor Dell Computer Corporation version "A09" date 05/15/2003
> bios0: Dell Computer Corporation Latitude C640
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP
> acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) UAR1(S3) USB0(S1)
> USB1(S1) USB2(S1) MODM(S3) PCIE(S3) MPCI(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PCIE)
> acpiprt3 at acpi0: bus -1 (MPCI)
> acpicpu0 at acpi0acpicpu0: struck PSS entry, core frequency equals  last
> acpicpu0: struck PSS entry, core frequency equals  last
> acpicpu0: invalid _PSS length
> : !C2(@50 io@0x8e4), C1(@1 halt!)
> acpipwrres0 at acpi0: PADA, resource for ADPT
> acpitz0 at acpi0: critical temperature is 99 degC
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model "LIP8120DLP" serial 5184 type LION oem
> "Sony Corp."
> acpibat1 at acpi0: BAT1 not present
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: PBTN
> acpibtn2 at acpi0: SBTN
> "PNP0F13" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> "PNP0700" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0401" at acpi0 not configured
> acpidock0 at acpi0: GDCK not docked (0)
> acpivideo0 at acpi0: VID_
> bios0: ROM list: 0xc/0xf000 0xcf000/0x800! 0xcf800/0x800!
> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82845 Host" rev 0x04
> intelagp0 at pchb0
> agp0 at intelagp0: aperture at 0xe800, size 0x400
> ppb0 at pci0 dev 1 function 0 "Intel 82845 AGP" rev 0x04
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00
> drm0 at radeondrm0
> radeondrm0: irq 11
> uhci0 at pci0 dev 29 function 0 "Intel 82801CA/CAM USB" rev 0x02: irq 11
> ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x42
> pci2 at ppb1 bus 2
> xl0 at pci2 dev 0 function 0 "3Com 3c905C 100Base-TX" rev 0x78: irq
> 11, address 00:08:74:48:40:d6
> exphy0 at xl0 phy 24: 3Com internal media interface
> cbb0 at pci2 dev 1 function 0 "TI PCI1420 CardBus" rev 0x00: irq 11
> cbb1 at pci2 dev 1 function 1 "TI PCI1420 CardBus" rev 0x00: irq 11
> ath0 at pci2 dev 3 function 0 "Atheros AR2413" rev 0x01: irq 11
> ath0: AR2413 7.8 phy 4.5 rf 5.6 eeprom 5.2, WOR3W, address 00:16:cf:53:07:71
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 4 device 0 cacheline 0x8, lattimer 0x20
> pcmcia0 at cardslot0
> cardslot1 at cbb1 slot 1 flags 0
> cardbus1 at cardslot1: bus 5 device 0 cacheline 0x8, lattimer 0x20
> pcmcia1 at cardslot1
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801CAM LPC" rev 0x02
> pciide0 at pci0 dev 31 function 1 "Intel 82801CAM IDE" rev 0x02: DMA,
> channel 0 configured to compatibility, channel 1 configured to
> compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI
> 5/cdrom removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> auich0 at pci0 dev 31 function 5 "Intel 82801CA/CAM AC97" rev 0x02:
> irq 11, ICH3 AC97
> ac97: codec id 0x4352595b (Cirrus Logic CS4205 rev 3)
> ac97: codec features mic channel, tone, simulated stereo, bass boost,
> 20 bit DAC, 18 bit ADC, SRS 3D
> audio0 at auich0
> "Intel 82801CA/CAM Modem" rev 0x02 at pci0 dev 31 

Re: MacBookAir5,2 panic at boot on aml running -current

[Mike Larkin]

On Mon, Aug 08, 2016 at 10:47:39AM +0200, si...@slackware.it wrote:
> Hello OpenBSD developers,
> I'm running -current on a MacBookAir5,2 and it panics very early at startup 
> with the following message: 
> https://sid77.slackware.it/tmp/macbookair_panic.jpg which I've transcribed 
> below.
> 
> 3402 Called: \_SB_.BAT0.UBIF
> 34e3 Called: \_SB_.BAT0._BIF
> 34e3 Called: \_SB_.BAT0._BIF
> panic: aml_die aml_convert:2075
> Stopped at Debugger+0x9: leave
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> * 0 0 0 0x1 0x200 0 swapper
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> 
> _aml_die() at _aml_die+0x193
> aml_convert() at aml_convert+0x6d
> aml_store() at aml_store+0x175
> aml_parse() at aml_parse+0xf4c
> aml_eval() at aml_eval+0x1c8
> aml_parse() at aml_parse+0x183d
> aml_eval() at aml_eval+0x1c8
> aml_evalnode() at aml_evalnode+0x74
> acpibat_getbif() at acpibat_getbif+0x73
> acpibat_getbif() at acpibat_getbif+0x5f
> acpibat_getbif() at acpibat_getbif+0x1bc
> acpibat_getbif() at acpibat_getbif+0x140
> end trace frame: 0x81abaac0, count 0
> 
> This is happening with both 6th and 7th August snapshots, wasn't happening on 
> the 5th and haven't tried the 8th August snapshot yet.
> I know this is not enough for a bug report, but the panic happens so early on 
> boot that the internal usb keyboard of the laptop is not working yet (except 
> for the power button) nor an external one (tested, just in case).
> 
> Cheers,
> Marco
> 
> -- 
> Marco Bonetti
> 

Following up on old emails ...

If this is still an issue, we'll need a sendbug from the snapshot that worked.

-ml

Re: restart after cpu halt

[Mike Larkin]

On Wed, Aug 31, 2016 at 10:04:24AM +0200, Martijn van Duren wrote:
> After a shutdown or suspend my laptop immediately starts up again.
> This issue is not present in Linux, or Windows.
> 
> acpidump can be found at: http://imperialat.at/acpidump.tar.gz
> 
> If anybody wants to play with it, the machine is at the hackathon.
> 

It's probably one of the S5 wake devices (PCIB, RP04, WNIC, or HST1).
Unfortunately, the AML appears to be busted (iasl dumps core trying
to disassemble it). Any options in the BIOS to selectively enable
or disable some devices may let you try to figure out which device
is causing the resume.

-ml

> martijn@
> 
> OpenBSD 6.0-current (GENERIC.MP) #0: Tue Aug 30 14:25:01 CEST 2016
> 
> mart...@harrypotter.imperialat.at:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4164415488 (3971MB)
> avail mem = 4033716224 (3846MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xa9e3f000 (31 entries)
> bios0: vendor Hewlett-Packard version "M73 Ver. 01.15" date 07/24/2015
> bios0: Hewlett-Packard HP ProBook 450 G2
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG ASF! TCPA SSDT SSDT SLIC MSDM FPDT 
> BGRT SSDT SSDT SSDT SSDT SSDT
> acpi0: wakeup devices LANC(S0) EHC1(S0) XHC_(S0) HS06(S0) PCIB(S5) RP03(S0) 
> NIC_(S0) RP04(S5) WNIC(S5) HST1(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.49 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> 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 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.15 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 40 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus -1 (PEGP)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus 7 (RP02)
> acpiprt3 at acpi0: bus 8 (RP03)
> acpiprt4 at acpi0: bus 9 (RP04)
> acpiprt5 at acpi0: bus -1 (RP07)
> acpiprt6 at acpi0: bus -1 (RP08)
> acpiprt7 at acpi0: bus 0 (PCI0)
> acpiec0 at acpi0
> acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: APPR, resource for HDEF
> acpipwrres1 at acpi0: COMP, resource for COM1
> acpipwrres2 at acpi0: LPP_, resource for LPT0
> acpipwrres3 at acpi0: PXP2, resource for RP02
> acpipwrres4 at 

Re: Macbook Air7,2 (Early 2015) doesn't suspend on lid close

[Mike Larkin]

On Sun, Sep 18, 2016 at 09:33:12AM +0530, Sunil Nimmagadda wrote:
> On Sat, Sep 17, 2016 at 05:27:16PM -0700, Mike Larkin wrote:
> > On Sat, Sep 17, 2016 at 10:10:32PM +0530, Sunil Nimmagadda wrote:
> > > Synopsis: Macbook Air7,2 (Early 2015) doesn't suspend on lid close
> > > Category: kernel/acpi
> > > Environment:
> > >   System  : OpenBSD 6.0
> > >   Details : OpenBSD 6.0-current (GENERIC.MP) #2461: Fri Sep 16 
> > > 20:27:42 MDT 2016
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > >   Architecture: OpenBSD.amd64
> > >   Machine : amd64
> > > Description:
> > >   Macbook Air7,2 fails to suspend on lid close. The screen, keyboard
> > >   backlight and led on urtwn0 are still on after closing the lid.
> > > 
> > >   Also, kernel intermittently freezes at this line while booting...
> > >   acpiec0 at acpi0 
> > > 
> > >   May be related, wsconsctl display.brightness=60 freezes and top shows...
> > >   6877 root 10 0 272K 220K idle acpilk 0:00% wsconsctl
> > > 
> > 
> > Does regular 'zzz' work?
> > 
> > -ml
> 
> Hi,
> 
> No, zzz/ZZZ doesn't work.
> 

Did it work before?

(this conversation is like pulling teeth or playing 20 questions).

Re: openBSD 6

[Mike Larkin]

On Sat, Sep 17, 2016 at 06:50:11PM +, Chri Fish wrote:
> hey
> 
> 
> i tried to install openBSD 6/amd64
> 
> 
> 1.
> 
> nfe0: watchodg timeout interval 1
> 
> 
> 2.
> 
> with vlan0
> 
> vlan0:watchdog timeout interval 1
> 
> 3.
> 
> i made the pkg_path
> 
> pkg_add -v nano
> 
> cant find nano
> 
> 
> pkg_add -v wget
> 
> cant find wget
> 
> 
> 4.
> 
> cd /usr/games
> 
> hangman
> 
> ---nothing ---
> 
> 
> nothing works
> 
> 
> 

Congratulations, you won the award for the most useless bug report in history.

Re: Macbook Air7,2 (Early 2015) doesn't suspend on lid close

[Mike Larkin]

On Sat, Sep 17, 2016 at 10:10:32PM +0530, Sunil Nimmagadda wrote:
> Synopsis: Macbook Air7,2 (Early 2015) doesn't suspend on lid close
> Category: kernel/acpi
> Environment:
>   System  : OpenBSD 6.0
>   Details : OpenBSD 6.0-current (GENERIC.MP) #2461: Fri Sep 16 
> 20:27:42 MDT 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> Description:
>   Macbook Air7,2 fails to suspend on lid close. The screen, keyboard
>   backlight and led on urtwn0 are still on after closing the lid.
> 
>   Also, kernel intermittently freezes at this line while booting...
>   acpiec0 at acpi0 
> 
>   May be related, wsconsctl display.brightness=60 freezes and top shows...
>   6877 root 10 0 272K 220K idle acpilk 0:00% wsconsctl
> 

Does regular 'zzz' work?

-ml

> OpenBSD 6.0-current (GENERIC.MP) #2461: Fri Sep 16 20:27:42 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error 
> ff
> real mem = 8469352448 (8077MB)
> avail mem = 8208166912 (7827MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afad000 (32 entries)
> bios0: vendor Apple Inc. version "MBA71.88Z.0166.B12.1602221953" date 
> 02/22/2016
> bios0: Apple Inc. MacBookAir7,2
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT 
> SSDT SSDT MCFG DMAR
> acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
> ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz, 1500.23 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> 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 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz, 1500.00 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> 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) i5-5250U CPU @ 1.60GHz, 1500.00 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> 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) i5-5250U CPU @ 1.60GHz, 1500.00 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpiec0 at acpi0
> acpimcfg0 at acpi0 addr 0xe000, bus 0-155
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG0)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus 2 (RP02)
> acpiprt4 at acpi0: bus 3 (RP03)
> acpiprt5 at acpi0: bus 5 (RP05)
> acpiprt6 at acpi0: bus 4 (RP06)
> acpicpu0 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@530 

Re: suspend to ram doesn't work on Toshiba Port??g?? Z30-A-12X

[Mike Larkin]

On Thu, Sep 15, 2016 at 10:26:43AM +0200, Sol??ne Rapenne wrote:
> Le 2016-09-06 18:09, Mike Larkin a ??crit??:
> > > 
> > 
> > Can you see if the "immediately resumes" problem is still there with
> > -current?
> > 
> > A fix went in at the recent hackathon that may fix this.
> > 
> > -ml
> > 
> 
> Hello,
> 
> It got better, now it goes into sleep and resume immediatly but doesn't
> crash. I unplugged ethernet and usb devices before going into suspend mode
> and it doesn't help.
> After resume, the system was feeling weird, a bit unresponsive when changing
> window and ultimately it froze after a few minutes, ping was down from
> outside and I had to keep the power button pushed to shutdown the computer.
> 

Without access to this hardware there's not much else I can suggest. Sorry.

-ml

> 
> Here are the logs when I do a suspend
> 
> Sep 15 09:54:28 solene apmd: system suspending
> Sep 15 09:54:29 solene /bsd: ugen0 at uhub3 port 2 "O2 O2Micro CCID SC
> Reader" rev 1.10/1.10 addr 5
> Sep 15 09:54:31 solene /bsd: uhub4 at uhub1 port 1 configuration 1 interface
> 0 "Intel Rate Matching Hub" rev 2.00/0.04 addr 2
> Sep 15 09:54:31 solene /bsd: wsmouse1 detached
> Sep 15 09:54:31 solene /bsd: ums0 detached
> Sep 15 09:54:31 solene /bsd: uhidev0 detached
> Sep 15 09:54:33 solene /bsd: ugen0 detached
> Sep 15 09:54:34 solene /bsd: uhub3 detached
> Sep 15 09:54:35 solene /bsd: uhub2 detached
> Sep 15 09:54:36 solene /bsd: uhub0 detached
> Sep 15 09:54:40 solene /bsd: uhub4 detached
> Sep 15 09:54:40 solene /bsd: uhub1 detached
> Sep 15 09:54:40 solene /bsd: uhub0 at usb0 configuration 1 interface 0
> "Intel xHCI root hub" rev 3.00/1.00 addr 1
> Sep 15 09:54:40 solene /bsd: uhub1 at usb1 configuration 1 interface 0
> "Intel EHCI root hub" rev 2.00/1.00 addr 1
> Sep 15 09:54:41 solene /bsd: iwm0: device timeout
> Sep 15 09:54:41 solene /bsd: iwm0: device timeout
> Sep 15 09:54:41 solene apmd: system resumed from sleep
> 

Re: Macbook Air7,2 (Early 2015) doesn't suspend on lid close

[Mike Larkin]

On Tue, Sep 20, 2016 at 08:40:21PM +0200, Joerg Jung wrote:
> On Sat, Sep 17, 2016 at 11:22:54PM -0700, Mike Larkin wrote:
> > On Sun, Sep 18, 2016 at 09:33:12AM +0530, Sunil Nimmagadda wrote:
> > > On Sat, Sep 17, 2016 at 05:27:16PM -0700, Mike Larkin wrote:
> > > > On Sat, Sep 17, 2016 at 10:10:32PM +0530, Sunil Nimmagadda wrote:
> > > > > Synopsis: Macbook Air7,2 (Early 2015) doesn't suspend on lid close
> > > > > Category: kernel/acpi
> > > > > Environment:
> > > > >   System  : OpenBSD 6.0
> > > > >   Details : OpenBSD 6.0-current (GENERIC.MP) #2461: Fri Sep 
> > > > > 16 20:27:42 MDT 2016
> > > > >
> > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > > 
> > > > >   Architecture: OpenBSD.amd64
> > > > >   Machine : amd64
> > > > > Description:
> > > > >   Macbook Air7,2 fails to suspend on lid close. The screen, 
> > > > > keyboard
> > > > >   backlight and led on urtwn0 are still on after closing the lid.
> > > > > 
> > > > >   Also, kernel intermittently freezes at this line while 
> > > > > booting...
> > > > >   acpiec0 at acpi0 
> > > > > 
> > > > >   May be related, wsconsctl display.brightness=60 freezes and top 
> > > > > shows...
> > > > >   6877 root 10 0 272K 220K idle acpilk 0:00% wsconsctl
> > > > > 
> > > > 
> > > > Does regular 'zzz' work?
> > > > 
> > > > -ml
> > > 
> > > Hi,
> > > 
> > > No, zzz/ZZZ doesn't work.
> > > 
> > 
> > Did it work before?
> 
> I own the same device, and I AFAIR it was never working. 
> 
> ...and yes this might be related to wsconsctl and brightness via
> inteldrm.
>  
> > (this conversation is like pulling teeth or playing 20 questions).
> 
> I'm sorry.
> 
> Any news on this? Did Sunil replied in private or something?
> 
> I'm willing to help and test things, so if you guys come up with
> something, e.g. a patch/diff, whatever, or if you need some more
> info/dumps let me know, please. I also own some other MacBook (Air)
> models where I can test things.
> 
> Thanks,
> Regards,
> Joerg (jung@)

No reply, unless I accidentally missed it (which is entirely possible).

zzz and ZZZ and closing the lid work by queueing a sleep task via
acpi_addtask. Regardless of which method you used, you'll end up in
acpi_sleep_task.

>From there, we end up in acpi_sleep_state which does the following:

1. sanity checks - does the machine support the Sx state you are requesting?
(S3 in the case of zzz or lidsuspend, S4 in the case of ZZZ).

2. enable the SST_WAKING indicator if the machine has one (eg, start the 
blinking
moon LED on a thinkpad, or pulse the power LED on some other machines)

3. turns off the screen via wsdisplay_suspend

4. if S4 (ZZZ), flush the buffercache

5. quiesce all devices by walking the device tree, calling the device's
activate method with a QUIESCE parameter. This is done with interrupts still
enabled, to allow certain devices to "pre-suspend" any state they need.

6. stop any I/Os in flight (bufq_quiesce)

7. stop/park any APs (multiprocessor machines)

8. disable interrupts

9. suspend all devices (similar to step 5). Devices are expected to copy their
hardware state somewhere "safe" (like their softc)

10. call ACPI _PTS

11. enable the SST_SLEEPING indicator (eg, the solid moon LED on a thinkpad)

12. call ACPI _GTS

13. clear existing ACPI event status (eg, whack the state of the power button
status)

14. enable wakeup for devices that are listed as "wakeup capable" for the 
selected Sx mode

15. go to sleep


In debugging failure to suspend issues (the above sequence covers only up
to suspend, not resume), read through that and match up the code in acpi.c
where you think your machine is having problems.

Start putting printfs or other debugger output in various places, this is
usually possible until somewhat late in the sequence. You may need to
disable the wsdisplay_suspend call temporarily (to see any printfs you add),
but this can have adverse effects on various machines if suspending from
console or from X and may cause hangs later in the sequence that wouldn't
have otherwise been there, or failures to resume video properly. YMMV.

Once you've identified the step or steps causing problems, come back and
let us know, and we can dig further. This is about all I can suggest without
having access to the hardware.

-ml

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

[Mike Larkin]

On Mon, Sep 26, 2016 at 08:37:23PM +0300, Özgür Kazanççı wrote:
> Today I bought a brand new HP 250 G5 laptop.
> 
> It has a humble, basic hardware configuration;
> 
> Intel® Celeron® Processor N3060 (2M Cache, up to 2.48 GHz)
> 4 GB RAM, 500 GB HDD
> 
> This is a new model HP laptop, made for basic Internet and Office needs.
> 
> I installed OpenBSD 6.0. Getting kernel panic during the boot. :(
> 
> I must say that OpenBSD would be a perfect choice for me on this laptop.
> But unfortunately, it seems it has troubles with the hardware of this PC.
> 
> The details are attached,
> 
> Many thanks in advance for your valuable efforts on making OpenBSD even
> better!
> 
> And please let me know whatever you'd need, whatever I could do for you to
> investigate the problem.
> 
> Kindest Regards.

I just committed a change that will print the type of operation region
that is failing. Please wait for the next snapshot and try a new kernel.
It will still fail, but it should at least give us more info.

-ml

Re: Troubleshooting laptop sleep/wake issue

[Mike Larkin]

On Sun, Nov 13, 2016 at 02:28:56PM -0800, Bryan Vyhmeister wrote:
> On Sun, Nov 13, 2016 at 03:28:27PM -0600, jordon wrote:
> > I recently got a new Thinkpad x260 that seems to run OpenBSD pretty
> > well, but it has some issues with suspend/resume.  It goes right to
> > sleep just fine when I close the lid, but when I open it, the screen
> > doesn???t wake up.  I can ssh into it from a different machine but the
> > display stays blank.  Also, I don???t think the power button works for
> > shutting it down.
> 
> I have a ThinkPad X260 as well. I haven't tried the power button for
> that purpose but resume will not work until inteldrm(4) has support for
> Intel Skylake graphics. Until then, I am using efifb(4) with wsfb(4) for
> Xorg which works reasonably well but without resume. A few developers
> have Skylake systems and Skylake inteldrm(4) support will get here at
> some point when some of the developers get the time to do it.
> Currently, inteldrm(4) supports up through Broadwell.
> 
> A newer -current snapshot will not make any difference for resume but
> there was an issue related to acpiec(4) that was fixed a few months
> back. Other than resume, my ThinkPad X260 works perfectly.
> 
> Bryan
> 

I've been told that ZZZ should work. (hibernate)

This may be an option for you. But it's slow.

-ml

Re: KERNEL PANIC: HP 250 G5 Notebook PC (W4M67EA)

[Mike Larkin]

On Wed, Oct 12, 2016 at 10:56:49AM +0300, Özgür Kazancci wrote:
> Hi again,
> 
> Just wanted to make sure that my last response has arrived you and wanted
> to ask if there's anything new (maybe your new requests from me?) regarding
> the issue?
> 

Yes, I got the email. Just been busy with other things. I'll get to it
when I have a chance.

-ml

> Thanks,
> Kind Regards.
> 
> 
> 
> On Sat, Oct 1, 2016 at 1:49 AM, Özgür Kazancci <ozgurkazan...@gmail.com>
> wrote:
> 
> > Here are the outputs after using the latest snapshot.
> >
> > Hope they'll be useful.
> >
> > Regards.
> >
> > On 28 Sep 2016 12:12, "Özgür Kazancci" <ozgurkazan...@gmail.com> wrote:
> >
> >> Mike,
> >>
> >> Before I try the latest snapshot including the commit you mentioned
> >> earlier, I wanted to give it a try on FreeBSD,
> >> The system works okay, doesn't hang, however, I get "ACPI Error:"
> >> messages in the console, from time to time.
> >> And I thought it would help -at least give an idea- to find a solution
> >> maybe?
> >> Screenshot is attached,
> >>
> >> Regards.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Sep 27, 2016 at 2:52 PM, Özgür Kazanççı <ozgurkazan...@gmail.com>
> >> wrote:
> >>
> >>> Thanks a lot, I'll be waiting for the next snapshot.
> >>>
> >>> Here are few additional steps that I tried so far;
> >>>
> >>> -I tried a new installation from scratch from the latest snapshot
> >>> available, didn't help.
> >>> -I wanted to try booting OpenBSD by turning the ACPI off, however, the
> >>> laptop's BIOS has absolutely NO option on ACPI/Power/Suspend/Resume, etc.
> >>> -I reduced the "heavyness" of the hardware in the BIOS; disabled a lot
> >>> of stuff (Such as ODD, Webcam, CardReader, Bluetooth, NetBoot, USB 3.0).
> >>> -HP Support page for HP 250 G5 Notebook had "Important BIOS Update" and
> >>> an important harddisk firmware update, - so I fetched them both and
> >>> updated, then done an another fresh installation, still, nothing has
> >>> changed.
> >>>
> >>> I'll be waiting for the next snapshot - to be able to send you further
> >>> details on the issue.
> >>> Many thanks,
> >>> Best,
> >>> Özgür.
> >>>
> >>>
> >>> On Tue, Sep 27, 2016 at 1:05 PM, Mike Larkin <mlar...@azathoth.net>
> >>> wrote:
> >>>
> >>>> On Mon, Sep 26, 2016 at 08:37:23PM +0300, Özgür Kazanççı wrote:
> >>>> > Today I bought a brand new HP 250 G5 laptop.
> >>>> >
> >>>> > It has a humble, basic hardware configuration;
> >>>> >
> >>>> > Intel® Celeron® Processor N3060 (2M Cache, up to 2.48 GHz)
> >>>> > 4 GB RAM, 500 GB HDD
> >>>> >
> >>>> > This is a new model HP laptop, made for basic Internet and Office
> >>>> needs.
> >>>> >
> >>>> > I installed OpenBSD 6.0. Getting kernel panic during the boot. :(
> >>>> >
> >>>> > I must say that OpenBSD would be a perfect choice for me on this
> >>>> laptop.
> >>>> > But unfortunately, it seems it has troubles with the hardware of this
> >>>> PC.
> >>>> >
> >>>> > The details are attached,
> >>>> >
> >>>> > Many thanks in advance for your valuable efforts on making OpenBSD
> >>>> even
> >>>> > better!
> >>>> >
> >>>> > And please let me know whatever you'd need, whatever I could do for
> >>>> you to
> >>>> > investigate the problem.
> >>>> >
> >>>> > Kindest Regards.
> >>>>
> >>>> I just committed a change that will print the type of operation region
> >>>> that is failing. Please wait for the next snapshot and try a new kernel.
> >>>> It will still fail, but it should at least give us more info.
> >>>>
> >>>> -ml
> >>>>
> >>>
> >>>
> >>

Re: 6.0 i386 MP kernel hang (6.0 SP and 5.9 MP kernels work)

[Mike Larkin]

On Sun, Oct 16, 2016 at 10:44:56PM -0400, Jim Faulkner wrote:
> Hi folks, I own a (fairly old) Fit-PC2i.  It has a 32-bit only Intel Atom
> dual core processor.  I ran the 5.9 i386 multiprocessor kernel without
> problem.  However, the 6.0 MP kernel hangs at:
> booting hd0a:/bsd: 7663236+2035096+189444+0+1085440 [72+518464+510159|
> 
> The 6.0 SP kernel works fine.  I patched the kernel today (Oct 16) and
> rebuilt GENERIC.MP but the patched MP kernel still hangs.
> 
> Please see the attached dumps.tar.gz for dmesg, usbdevs, pcidump, and
> acpidump output.  Let me know what other information I can provide.
> 

Can you help by bisecting diffs? There wasn't much changed in that time
frame that I could envision causing a hang here.

Thanks.

-ml

Re: 6.0 i386 MP kernel hang (6.0 SP and 5.9 MP kernels work)

[Mike Larkin]

On Mon, Oct 17, 2016 at 01:31:36PM -0700, Mike Larkin wrote:
> On Sun, Oct 16, 2016 at 10:44:56PM -0400, Jim Faulkner wrote:
> > Hi folks, I own a (fairly old) Fit-PC2i.  It has a 32-bit only Intel Atom
> > dual core processor.  I ran the 5.9 i386 multiprocessor kernel without
> > problem.  However, the 6.0 MP kernel hangs at:
> > booting hd0a:/bsd: 7663236+2035096+189444+0+1085440 [72+518464+510159|
> > 
> > The 6.0 SP kernel works fine.  I patched the kernel today (Oct 16) and
> > rebuilt GENERIC.MP but the patched MP kernel still hangs.
> > 
> > Please see the attached dumps.tar.gz for dmesg, usbdevs, pcidump, and
> > acpidump output.  Let me know what other information I can provide.
> > 
> 
> Can you help by bisecting diffs? There wasn't much changed in that time
> frame that I could envision causing a hang here.
> 
> Thanks.
> 
> -ml
> 

PS, all you need to bisect is the kernel stuff (obviously). If it gets past
the point of hanging, you've found the offending commit.

I thought it may have been related to W^X, but you said 5.9 worked, and 
most of that was already in for 5.9. You could try to validate that part
by commenting out the "detect PAE" code in locore.s and see if it properly
falls back to no-PAE on your MP configuration.

-ml

Re: pmap_remove_ptes_86: unmanaged page marked PG_PVLIST caused 1 panic on OpenBSD 6.0

[Mike Larkin]

On Fri, Jan 13, 2017 at 09:26:33PM +, Craig Skinner wrote:
> On Fri, 13 Jan 2017 12:54:27 + (GMT) skin...@britvault.co.uk wrote:
> 
> > savecore: writing compressed core to /var/crash/bsd.0.core.Z
> > savecore: writing compressed kernel to /var/crash/bsd.0.Z
> 
> These are now in http://web.Britvault.Co.UK/tmp/
> 

Probably not much we can do since it was a 1 time thing, but I'll grab
these and take a look tonight, maybe I can see what happened.

-ml

Re: X crashes after suspend/resume cycle and keyboard becomes unusable

[Mike Larkin]

On Tue, Mar 21, 2017 at 01:23:07AM +, Raf Czlonka wrote:
> >Synopsis:X crashes after suspend/resume cycle and keyboard becomes 
> >unusable
> >Category:system
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1-beta (GENERIC.MP) #37: Fri Mar 17 07:46:47 
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After suspend/resume cycle, X crashes and keyboard becomes
>   unusable, producing unusual characters - ones which are not
>   present on current layout, i.e. inverted exclamation mark,
>   yen or cent currency characters, (R), etc. - thus preventing
>   from logging onto the system again.
> 
>   Afterwards, I'm unable to interact with the system, unless
>   I'm connected to a network on which I have another machine
>   I can SSH from to the laptop.
> 
>   Xorg.0.log attached.
> 
>   I found this thread (http://marc.info/?t=14844776961)
>   which sounds pretty much exactly what I'm experiencing but
>   this one didn't go very far.
> 

As I mentioned to the original filer of this bug, you'll have to help us
narrow this down. The previous answer of "some time between october 24 and
january 15, with some other unrelated issues seen around december 2" doesn't
help us. If you can point to a commit which broke it by bisecting kernels,
it will help us immensely.

-ml

>   I've been running -current on this laptop since last year
>   and, as far as I can remember, this has never worked.
> 
> >How-To-Repeat:
>   Unplug laptop from main power, close the lid, wait a couple
>   of seconds, open the lid - X crashes before ones eyes and
>   the keyboard becomes unusable.
> 
> >Fix:
>   No fix other than not using suspend on the laptop - only
>   closing the lid while plugged into mains so that it does
>   *not* suspend.
> 
>   If I'm connected to a network on which I have another machine
>   (not always available or even possible), I can connect to
>   the laptop via SSH and start xenodm(1) again.
> 
> 
> dmesg:
> OpenBSD 6.1-beta (GENERIC.MP) #37: Fri Mar 17 07:46:47 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error 1f
> real mem = 8473620480 (8081MB)
> avail mem = 8212135936 (7831MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ad14000 (63 entries)
> bios0: vendor Apple Inc. version "MBP91.88Z.00D3.B0D.1602221713" date 
> 02/22/2016
> bios0: Apple Inc. MacBookPro9,2
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT 
> SSDT SSDT SSDT SSDT SSDT DMAR MCFG
> acpi0: wakeup devices P0P2(S3) PEG1(S3) EC__(S4) GMUX(S3) HDEF(S3) RP01(S3) 
> GIGE(S3) SDXC(S3) RP02(S3) ARPT(S3) RP03(S3) EHC1(S3) EHC2(S3) XHC1(S3) 
> ADP1(S4) LID0(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.73 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: TSC frequency 2494725560 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.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.33 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> 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) i5-3210M CPU @ 2.50GHz, 2494.33 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,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> 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) i5-3210M 

Re: Failing resume from hibernate (IntelDRM related?)

[Mike Larkin]

On Tue, Aug 15, 2017 at 05:05:59PM +0200, Alessandro DE LAURENZIS wrote:
> Mike, all,
> 
> On Sat 12/08/2017 19:01, Alessandro DE LAURENZIS wrote:
> > Hello Mike,
> > 
> > > > root on sd0a (ff014e14e96d5c40.a) swap on sd0b dump on sd0b
> > > > WARNING: / was not properly unmounted
> > 
> > so: it tries to unpack a hibernated image, but then it is like the
> > previous hibernation didn't complete, since a fsck is forced.
> > 
> > But I was just reviewing this stuff, and can give some additional
> > information: the IntelDRM doesn't play any roles here; actually what I'm
> > observing is that an unmodified /bsd works flawlessly, instead the
> > hibernation "fails" after a modification with config(8); I just do the
> > following:
> > 
> > [snip]
> > sh> config -o /bsd.noulpt -e /bsd
> > OpenBSD 6.1-current (GENERIC.MP) #44: Thu Aug  3 12:12:07 MDT 2017
> >   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >   Enter 'help' for information
> >   ukc> disable ulpt*
> >   299 ulpt* disabled
> >   ukc> quit
> > [snip]
> > 
> > and then rebooting with /bsd.noulpt and hibernating/resuming, I see the
> > problem.
> > 
> > Does that make any sense?
> 
> after a discussion with semarie@ on #openbsd, the point here is that in
> /etc/rc we have:
> 
> ln -fh /bsd /bsd.booted
> 
> so in order to be compatible with current KARL/hibernation/resume mechanism,
> the booted kernel *must* be called "/bsd".
> 

Although this may be true, that's the default and IMO doesn't need to be
documented as such. But thanks nonetheless for clarifying this.

-ml

> I think a mention in https://www.openbsd.org/faq/current.html could be
> beneficial to other users, too.
> 
> Thanks for your time (and sorry again for the poor report).
> 
> -- 
> Alessandro DE LAURENZIS
> [mailto:jus...@atlantide.t28.net]
> LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: sys/arch/i386/i386/bios.c won't compile if NACPI==0 and NAPM>0

[Mike Larkin]

On Fri, Jul 14, 2017 at 03:39:25PM -0700, Nick Briggs wrote:
> 
> > Synopsis:  sys/arch/i386/i386/bios.c won't compile if NACPI ==0 and 
> > NAPM>0
> > Category:  system
> > Environment:
>System  : OpenBSD 6.1
>Details : OpenBSD 6.1-stable (PIGEON) #5: Thu Jul 13 17:09:51 PDT 
> 2017
> briggs@pigeon:/usr/obj/sys/arch/i386/compile/PIGEON
> 
>Architecture: OpenBSD.i386
>Machine : i386
> > Description:
> 
> In  bios.c:171 "usingacpi" is declared with
> 
> #if NACPI > 0
> int usingacpi = 0;
> #endif
> 
> but at bios.c:390, we find
> 
> #if NAPM > 0
> if (usingacpi == 0 && apm && ncpu < 2 && smbiosrev < 240) {
> 
> > How-To-Repeat:
> 
>recompile kernel for i386 with apm but without acpi in the 
> configuration.
> 
> > Fix:
> 
> One possibility:
> 
> Index: sys/arch/i386/i386/bios.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
> retrieving revision 1.115
> diff -u -p -r1.115 bios.c
> --- sys/arch/i386/i386/bios.c   7 Mar 2016 05:32:46 -   1.115
> +++ sys/arch/i386/i386/bios.c   14 Jul 2017 19:33:20 -
> @@ -171,7 +171,7 @@ biosattach(struct device *parent, struct
> volatile u_int8_t *va;
> char scratch[64], *str;
> int flags, smbiosrev = 0, ncpu = 0, isa_hole_exec = 0;
> -#if NACPI > 0
> +#if NACPI > 0 || NAPM > 0
> int usingacpi = 0;
>  #endif
>  
> Alternatively, make the reference to usingacpi conditional on NACPI > 0.
> 
> 

what are you trying to do here?

We generally don't support bizarre custom kernel configurations.

-ml

Re: run(4) driver kernel panic OBSD 6.0 amd64 on boot

[Mike Larkin]

On Fri, Aug 04, 2017 at 10:26:37PM +0100, Stuart Henderson wrote:
> On 2017/08/04 23:05, Denis wrote:
> > OpenBSD 6.0-stable (CUSTOM.MP) #8: Fri Mar 31 15:01:38
> > r...@root.name:/usr/src/sys/arch/amd64/compile/CUSTOM.MP
> 
> That is still 6.0:
> 

It's also some wacky "CUSTOM.MP" configuration.

> > On 04.08.2017 15:07, Stefan Sperling wrote:
> > > Please try -current. I will not look into bug reports for 6.0.
> > > There are already too many bug reports I need to handle.
> 
> ...
> 

Re: panic on resume in acpitz_setfan

[Mike Larkin]

On Mon, Aug 14, 2017 at 12:05:59AM +0100, Laurence Tratt wrote:
> >Synopsis:panic on resume in acpitz_setfan
> >Category:kernel
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1-current (GENERIC.MP) #1: Fri Aug 11 21:26:07 
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> The following panic happened immediately after a resume (the second since
> the machine was switched on) on the Aug 11th snapshot:
> 
>   uvm_fault(0x81b3ff8, 0x20003, 0, 1) -> e
>   kernel: page fault trap, code=0
>   Stopped at acpitz_setfan+0x8c:   movq 0(%rax), %rsi
> 
>   https://imagebin.ca/v/3Wmq884ayBSf
> 
> This happened before the keyboard was reattached, so I couldn't get any
> further information from the panic.
> >How-To-Repeat:
>   Unknown
> >Fix:
>   Unknown
> 

Can you send an acpidump for this machine please? You can find it in
/var/db/acpi ...

-ml

> dmesg:
> OpenBSD 6.1-current (GENERIC.MP) #1: Fri Aug 11 21:26:07 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17028448256 (16239MB)
> avail mem = 16506011648 (15741MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xc3202000 (89 entries)
> bios0: vendor American Megatrends Inc. version "3301" date 02/10/2017
> bios0: ASUSTeK COMPUTER INC. Z170M-PLUS
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT BGRT MCFG SSDT FIDT SSDT SSDT HPET SSDT 
> SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
> SIO1(S3) UAR1(S4) PS2K(S4) PS2M(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) 
> PXSX(S4) RP11(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-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: TSC frequency 400800 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 23MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> 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-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> 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-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> 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 addr 0xf800, bus 0-63
> 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 4 (RP09)
> acpiprt5 at acpi0: bus 

Re: panic on resume in acpitz_setfan

[Mike Larkin]

On Sun, Aug 20, 2017 at 11:21:32AM -0700, Mike Larkin wrote:
> On Mon, Aug 14, 2017 at 12:05:59AM +0100, Laurence Tratt wrote:
> > >Synopsis:  panic on resume in acpitz_setfan
> > >Category:  kernel
> > >Environment:
> > System  : OpenBSD 6.1
> > Details : OpenBSD 6.1-current (GENERIC.MP) #1: Fri Aug 11 21:26:07 
> > MDT 2017
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > The following panic happened immediately after a resume (the second 
> > since
> > the machine was switched on) on the Aug 11th snapshot:
> > 
> >   uvm_fault(0x81b3ff8, 0x20003, 0, 1) -> e
> >   kernel: page fault trap, code=0
> >   Stopped at acpitz_setfan+0x8c:   movq 0(%rax), %rsi
> > 
> >   https://imagebin.ca/v/3Wmq884ayBSf
> > 
> > This happened before the keyboard was reattached, so I couldn't get any
> > further information from the panic.
> > >How-To-Repeat:
> > Unknown
> > >Fix:
> > Unknown
> > 
> 
> Can you send an acpidump for this machine please? You can find it in
> /var/db/acpi ...
> 
> -ml
> 

Also ... I've been discussing this with another developer and we're both stumped
as to how this can happen. Can you see if you can reproduce this reliably too?

-ml

> > dmesg:
> > OpenBSD 6.1-current (GENERIC.MP) #1: Fri Aug 11 21:26:07 MDT 2017
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 17028448256 (16239MB)
> > avail mem = 16506011648 (15741MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xc3202000 (89 entries)
> > bios0: vendor American Megatrends Inc. version "3301" date 02/10/2017
> > bios0: ASUSTeK COMPUTER INC. Z170M-PLUS
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT BGRT MCFG SSDT FIDT SSDT SSDT HPET SSDT 
> > SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2
> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
> > SIO1(S3) UAR1(S4) PS2K(S4) PS2M(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) 
> > PXSX(S4) RP11(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-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: TSC frequency 400800 Hz
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 23MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> > 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-6700K CPU @ 4.00GHz, 4008.00 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,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> > 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-6700K CPU @ 4.0

Re: time runs at 50% inside a vmm host

[Mike Larkin]

On Fri, May 12, 2017 at 05:08:50PM +0200, Paul de Weerd wrote:
> On Fri, May 12, 2017 at 04:35:40PM +0200, Paul de Weerd wrote:
> | Thanks for your reply.  Yours and an off-list reply both pointed at
> | the HZ parameter.  I built a kernel with HZ=1000, and things now work
> | much better in the vm.
> 
> I spoke too soon :-(
> 
> Things do work better, but the clock is still slow:
> 
> [weerd@vm1] $ rdate -npv ${N}; uptime
> Fri May 12 16:50:14 CEST 2017
> rdate: adjust local clock by 124.798956 seconds
>  4:48PM  up 16 mins, 1 user, load averages: 0.00, 0.00, 0.00
> 
> So, in 16 minutes, the clock is 2 minutes behind.  So, a lot better,
> but still falling behind.
> 
> [weerd@vm1] $ rdate -npv ${N}; time sleep 600; rdate -npv ${N} 
> Fri May 12 16:51:47 CEST 2017
> rdate: adjust local clock by 135.359214 seconds
>10m03.01s real 0m00.00s user 0m00.00s system
> Fri May 12 17:03:08 CEST 2017
> rdate: adjust local clock by 213.572802 seconds
> 
> Which turns out to be almost 8 seconds per minute.
> 
> Paul 'WEiRD' de Weerd
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

Known issue.

Re: VM guest restarting

[Mike Larkin]

On Thu, Jun 08, 2017 at 06:33:35AM -0700, Mike Larkin wrote:
> On Fri, Jun 02, 2017 at 08:38:14AM -0400, Bryan Steele wrote:
> > On Fri, Jun 02, 2017 at 05:56:32AM -0500, Michael Graves wrote:
> > > On 2017-06-01 23:37, Mike Larkin wrote:
> > > > 
> > > > This is the second report I've seen of the FX4100 crashing. I'll have to
> > > > add
> > > > some diagnostic code to see why it fails since I don't have access to
> > > > this
> > > > hardware.
> > > > 
> > > > One thing I see that's odd is you are using the old style of booting.
> > > > Can you
> > > > make sure you got the firmware via fw_update after the new snap?
> > > > 
> > > > -ml
> > > 
> > > I ran fw_update without any packages being updated.  Here is the output of
> > > 'fw_update -i'  and a md5 sum of the vmm* files if that helps.
> > > 
> > > # fw_update -i
> > > Installed: radeondrm-firmware-20150927 vmm-firmware-1.10.2p3
> > > 
> > > # md5 /etc/firmware/vmm-bios*
> > > MD5 (/etc/firmware/vmm-bios) = 2946eaf040aa4fd31c13edd442b36665
> > > MD5 (/etc/firmware/vmm-bios-license) = 4bb44edd8d967f805ae4df6386c59aaa
> > > 
> > >
> > 
> > I'm the other FX-4100 owner, I think Mike wanted you to test if BIOS
> > boots work for you, for me I get SeaBIOS and boot(8) out, but crashes
> > and restarts the VM as soon as it loads the kernel.
> > 
> > For BIOS boots, you simply don't need to pass a kernel image via
> > -b or boot, just a disk image with a valid boot sector.
> > 
> > -Bryan.
> > 
> 
> So Bryan and I have made a little progress here, we've made it past this error
> by disabling NX in the guest (which makes no sense since the CPU supports it
> and the feature is enabled properly). However, it hangs later with an 
> interrupt
> issue.
> 
> Still looking at it. Looks like this cpu is the problem child model of AMD.
> 
> -ml
>

I just committed part of the fix. While this does not yet make this family of
CPUs usable for vmm, we are getting closer.

-ml 

Re: Suspend-to-disk doesn't work anymore

[Mike Larkin]

On Mon, May 22, 2017 at 08:55:31PM +0200, Mike Belopuhov wrote:
> On Mon, May 22, 2017 at 20:20 +0200, Sebastien Marie wrote:
> > On Mon, May 22, 2017 at 07:32:07PM +0200, Mike Belopuhov wrote:
> > > > 
> > > > With the last commit to revert AES_XTS to rijndael, I pushed it on
> > > > top of the tested tree (7 days old). The hibernate/resume works again.
> > > > 
> > > > It makes it to confirm the problem is related to the switch to
> > > > constant-time-aes in the context of full-disk-encryption.
> > > >
> > > 
> > > Thanks for verifying this.  I've looked through the sr_hibernate_io
> > > (that's hib->io_func) but couldn't find anything wrong with it. The
> > > only thing that springs to mind is that AES_CTX and therefore the
> > > XTS context (aes_xts_ctx) is larger and requires more stack space.
> > > Though I can't see what might be affected by that.
> > 
> > I quickly check the difference of struct size and come back with some
> > idea to test.
> > 
> > - aes_xts_ctx based on AES_CTX  has sizeof()=1464
> > - aes_xts_ctx based on rijndael_ctx has sizeof()=992
> > 
> > 
> > do you think just adding padding of 472 (1464-992) at end of `struct
> > aes_xts_ctx' (rijndael_ctx version) would be enough to test it ?
> > 
> > Something like:
> > 
> > diff --git a/sys/crypto/xform.c b/sys/crypto/xform.c
> > index 71e173b44..9775d030c 100644
> > --- a/sys/crypto/xform.c
> > +++ b/sys/crypto/xform.c
> > @@ -125,6 +125,7 @@ struct aes_xts_ctx {
> > rijndael_ctx key1;
> > rijndael_ctx key2;
> > u_int8_t tweak[AES_XTS_BLOCKSIZE];
> > +   u_int8_t _pad[472];
> >  };
> > 
> >  /* Helper */
> >
> 
> Good question.  I would try both in the end of the structure and in
> the beginning, in attempt to at least rule out stack corruption.
> 
> > 
> > if the hibernate/resume process is able to complete with the padded
> > version, we could exclude the struct size of the equation. and if the
> > process fail, it means the size matters.
> >
> 
> I would agree with this.
> 
> > any additional thing to do for testing padding (initialisation or
> > something else) ? you know better than me this subsystem :)
> >
> 
> Nothing springs to mind, but I didn't have time to investigate
> any further yet.
> 

Is the new AES implementation side effect free? It cannot touch any memory
outside the scratch page used by the sr crypto suspend routine. 

-ml

Re: Suspend-to-disk doesn't work anymore

[Mike Larkin]

On Mon, May 22, 2017 at 09:39:57PM +0200, Mike Belopuhov wrote:
> On Mon, May 22, 2017 at 12:34 -0700, Mike Larkin wrote:
> > On Mon, May 22, 2017 at 08:55:31PM +0200, Mike Belopuhov wrote:
> > > On Mon, May 22, 2017 at 20:20 +0200, Sebastien Marie wrote:
> > > > On Mon, May 22, 2017 at 07:32:07PM +0200, Mike Belopuhov wrote:
> > > > > > 
> > > > > > With the last commit to revert AES_XTS to rijndael, I pushed it on
> > > > > > top of the tested tree (7 days old). The hibernate/resume works 
> > > > > > again.
> > > > > > 
> > > > > > It makes it to confirm the problem is related to the switch to
> > > > > > constant-time-aes in the context of full-disk-encryption.
> > > > > >
> > > > > 
> > > > > Thanks for verifying this.  I've looked through the sr_hibernate_io
> > > > > (that's hib->io_func) but couldn't find anything wrong with it. The
> > > > > only thing that springs to mind is that AES_CTX and therefore the
> > > > > XTS context (aes_xts_ctx) is larger and requires more stack space.
> > > > > Though I can't see what might be affected by that.
> > > > 
> > > > I quickly check the difference of struct size and come back with some
> > > > idea to test.
> > > > 
> > > > - aes_xts_ctx based on AES_CTX  has sizeof()=1464
> > > > - aes_xts_ctx based on rijndael_ctx has sizeof()=992
> > > > 
> > > > 
> > > > do you think just adding padding of 472 (1464-992) at end of `struct
> > > > aes_xts_ctx' (rijndael_ctx version) would be enough to test it ?
> > > > 
> > > > Something like:
> > > > 
> > > > diff --git a/sys/crypto/xform.c b/sys/crypto/xform.c
> > > > index 71e173b44..9775d030c 100644
> > > > --- a/sys/crypto/xform.c
> > > > +++ b/sys/crypto/xform.c
> > > > @@ -125,6 +125,7 @@ struct aes_xts_ctx {
> > > > rijndael_ctx key1;
> > > > rijndael_ctx key2;
> > > > u_int8_t tweak[AES_XTS_BLOCKSIZE];
> > > > +   u_int8_t _pad[472];
> > > >  };
> > > > 
> > > >  /* Helper */
> > > >
> > > 
> > > Good question.  I would try both in the end of the structure and in
> > > the beginning, in attempt to at least rule out stack corruption.
> > > 
> > > > 
> > > > if the hibernate/resume process is able to complete with the padded
> > > > version, we could exclude the struct size of the equation. and if the
> > > > process fail, it means the size matters.
> > > >
> > > 
> > > I would agree with this.
> > > 
> > > > any additional thing to do for testing padding (initialisation or
> > > > something else) ? you know better than me this subsystem :)
> > > >
> > > 
> > > Nothing springs to mind, but I didn't have time to investigate
> > > any further yet.
> > > 
> > 
> > Is the new AES implementation side effect free? It cannot touch any memory
> > outside the scratch page used by the sr crypto suspend routine. 
> > 
> > -ml
> 
> It doesn't touch any memory except for its context which is on the stack.
> If this stack must fit into the scratch page, I don't see any indication
> of enforcing it or a comment explaining it.  aes_xts_ctx is not part of
> the "*my = page;" structure.
> 

A private stack is in use while hibernate is occurring, so as long as the stack
doesn't grow past 3 pages it should be ok. The *my = page is for any extra
working area the I/O routines need.

-ml

Re: VM guest restarting

[Mike Larkin]

On Thu, Jun 01, 2017 at 08:03:40AM -0500, Michael Graves wrote:
> > Synopsis:  VM in constand boot loop
> > Category:  amd64
> > Environment:
> System  : OpenBSD 6.1
> Details : OpenBSD 6.1-current (GENERIC.MP) #88: Wed May 31
> 19:06:15 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> > Description:
> running vmd and trying to create a new virtual machine does not
> work.  running vmd(8) with -dvv flags shows the VM constantly restarting.
> Happy to help toubleshoot the problem.  Output below
> 

This is the second report I've seen of the FX4100 crashing. I'll have to add
some diagnostic code to see why it fails since I don't have access to this
hardware.

One thing I see that's odd is you are using the old style of booting. Can you
make sure you got the firmware via fw_update after the new snap?

-ml

> corpus# vmd -d -vv
> startup
> /etc/vm.conf:18: switch "uplink" registered
> /etc/vm.conf:37: vm "obsd61" registered (disabled)
> vm_priv_brconfig: interface bridge0 description switch1-uplink
> vm_priv_brconfig: interface bridge0 add em0
> vmd_configure: not creating vm obsd61 (disabled)
> vm_opentty: vm obsd61 tty /dev/ttyp1 uid 0 gid 4 mode 620
> vm_priv_ifconfig: interface tap0 description vm1-if0-obsd61
> vm_priv_ifconfig: interface bridge0 add tap0
> obsd61: started vm 1 successfully, tty /dev/ttyp1
> loadfile_elf: loaded ELF kernel
> run_vm: initializing hardware for vm obsd61
> virtio_init: vm "obsd61" vio0 lladdr 54:55:11:11:11:01
> run_vm: starting vcpu threads for vm obsd61
> vcpu_reset: resetting vcpu 0 for vm 7410
> run_vm: waiting on events for VM obsd61
> vm_priv_ifconfig: interface tap0 description vm1-if0-obsd61
> vm_priv_ifconfig: interface bridge0 add tap0
> obsd61: started vm 1 successfully, tty /dev/ttyp1
> loadfile_elf: loaded ELF kernel
> run_vm: initializing hardware for vm obsd61
> virtio_init: vm "obsd61" vio0 lladdr 54:55:11:11:11:01
> run_vm: starting vcpu threads for vm obsd61
> vcpu_reset: resetting vcpu 0 for vm 7411
> ... repeat ...
> 
> 
> 
> corpus# cat /etc/vm.conf
> sets="/home/OpenBSD/snapshots/amd64/"
> 
> switch "uplink" {
> add em0
> }
> 
> vm "obsd61" {
> boot $sets "bsd.rd"
> memory 512M
> disk "/home/images/obsd-snap1.img"
> disk $sets "install61.fs"
> interface {
> lladdr 54:55:11:11:11:01
> switch "uplink"
> }
> }
> 
> > How-To-Repeat:
> just running vmd causes it to loop until stopped.
> > Fix:
> Unknown
> 
> 
> dmesg:
> OpenBSD 6.1-current (GENERIC.MP) #88: Wed May 31 19:06:15 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16877486080 (16095MB)
> avail mem = 16360189952 (15602MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfc090 (24 entries)
> bios0: vendor American Megatrends Inc. version "P1.20" date 05/21/2012
> bios0: ASRock 960GM/U3S3 FX
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB AAFT HPET SSDT
> acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4)
> PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) UAR1(S4) P0PC(S4) UHC1(S4)
> UHC2(S4) UHC3(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 16 (boot processor)
> cpu0: AMD FX(tm)-4100 Quad-Core Processor, 3607.58 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC
> cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line
> 16-way L2 cache, 8MB 64b/line 64-way L3 cache
> cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully
> associative
> cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully
> associative
> cpu0: TSC frequency 3607581460 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 200MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 17 (application processor)
> cpu1: AMD FX(tm)-4100 Quad-Core Processor, 3607.16 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TOPEXT,ITSC
> cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line
> 16-way L2 cache, 8MB 64b/line 64-way L3 cache
> cpu1: ITLB 48 4KB entries fully associative, 

Re: Race condition (?) and VM hang in vmd with Alpine Linux as guest

[Mike Larkin]

On Thu, Jun 01, 2017 at 12:58:27PM +0200, Martin Pieuchot wrote:
> On 01/06/17(Thu) 10:47, Martin Pieuchot wrote:
> > On 31/05/17(Wed) 22:43, Gregor Best wrote:
> > > Hi people,
> > > 
> > > with a fresh snapshot (according to the dates on the FTP server from
> > > today), and a kernel built from CVS from about 20:15 UTC+1, vmd's child
> > > processes reproducibly enter an infinite loop relatively early after
> > > booting an Alpine Linux VM. The problem is not reproducible when booting
> > > my /bsd.rd.
> > 
> > Thanks for reporting the problem, it's certainly related to the new
> > condvard.  I reverted librthread to the old implementation for the
> > moment.
> 
> Apparently it is not.  I tried to track the problem down and even with
> reverted libpthread and a pre-hackathon vmd(8), I have an interrupt
> problem in my guest. 
> 

I can repro this locally. It's probably a bug that's been hitting us randomly
since Cambridge but I've been unable to nail it down. Certainly timing related.

Since it's now more pronounced, Ill try to track it down over the next few days.

-ml

> In my case I'm trying to install alpine linux using your ISO:
> 
>   # cat /etc/vmd.conf
>   vm "alpine" {
>   memory 128M
>   disk "/home/vmd/alpine"
>   local interface
>   disable
>   }
>   # vmctl start alpine -d alpine-virt-3.6.0-x86_64.iso  -c 
> 
> The host freeze once I typed "setup-alpine":
> 
>   localhost:~# setup-alpine 
> 7% [##]
> 
> A that time one of the threads is doing a crazy loop entering/existing
> thrsleep:
> 
>   PID  TID PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> 53152   557765  280  515M   10M onproc/2  - 0:12  0.00% vmd
> 53152   193294   20  515M   10M sleep/1   kqread0:01  0.00% vmd
> 53152   123587  280  515M   10M idle  thrslee   0:00  0.00% vmd
> 
> Here's what the two non-IDLE threads are doing in a loop:
> 
> 53152/193294  vmd  RET   kevent 0
> 53152/193294  vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x115e7354e140)
> 53152/193294  vmd  STRU  struct timespec { 2785.967019509 }
> 53152/193294  vmd  RET   clock_gettime 0
> 53152/193294  vmd  CALL  ioctl(4,_IOW('V',6,0xc),0x115e7354e0f4)
> 53152/193294  vmd  RET   ioctl 0
> 53152/193294  vmd  CALL  __thrwakeup(0x115e6c571638,1)
> 53152/193294  vmd  RET   __thrwakeup 0
> 53152/193294  vmd  CALL  
> kevent(5,0x115dee35f000,0,0x115e7971d800,64,0x115e7354e110)
> 53152/193294  vmd  STRU  struct timespec { 0.00000 }
> 53152/557765  vmd  RET   __thrsleep 0
> 53152/557765  vmd  CALL  ioctl(4,_IOW('V',6,0xc),0x115ebba883c4)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,PVBUSIOC_KVWRITE,0x115e5e28fbe0)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,_IOW('V',6,0xc),0x115ebba883c4)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,PVBUSIOC_KVWRITE,0x115e5e28fbe0)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,_IOW('V',6,0xc),0x115ebba883c4)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,PVBUSIOC_KVWRITE,0x115e5e28fbe0)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,_IOW('V',6,0xc),0x115ebba883c4)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,PVBUSIOC_KVWRITE,0x115e5e28fbe0)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,_IOW('V',6,0xc),0x115ebba883c4)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  ioctl(4,PVBUSIOC_KVWRITE,0x115e5e28fbe0)
> 53152/557765  vmd  RET   ioctl 0
> 53152/557765  vmd  CALL  
> __thrsleep(0x115e6c571638,CLOCK_REALTIME,0,0x115e9c14c8c0,0x115e6c571704)
> 
> What's interesting is that if I press a key on my keyboard, the install
> goes further:
> 
>   localhost:~# setup-alpine 
>14% [# ]
> 
> So I assume it's an interrupt related problem.  Pressing a 'key' works up
> to some point.  Then the host completely hang.  At this moment both threads
> are waiting in the kernel:
> 
>   PID  TID PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> 53152   193294  640  515M   10M onproc/2  - 1:36 98.68% vmd
> 53152   557765  280  515M   10M sleep/3   thrslee   0:15  0.00% vmd
> 53152   123587  280  515M   10M idle  thrslee   0:00  0.00% vmd
> 
> Here's what ktrace reports, similar to what tedu@ reported [0] as well:
> 
> 53152/193294  vmd  STRU  struct timespec { 0.001893000 }
> 53152/193294  vmd  STRU  struct kevent { ident=8, filter=EVFILT_READ, 
> flags=0x1, fflags=0<>, data=7, udata=0x115bd87a6638 }
> 53152/193294  vmd  RET   

Re: VM guest restarting

[Mike Larkin]

On Fri, Jun 02, 2017 at 08:38:14AM -0400, Bryan Steele wrote:
> On Fri, Jun 02, 2017 at 05:56:32AM -0500, Michael Graves wrote:
> > On 2017-06-01 23:37, Mike Larkin wrote:
> > > 
> > > This is the second report I've seen of the FX4100 crashing. I'll have to
> > > add
> > > some diagnostic code to see why it fails since I don't have access to
> > > this
> > > hardware.
> > > 
> > > One thing I see that's odd is you are using the old style of booting.
> > > Can you
> > > make sure you got the firmware via fw_update after the new snap?
> > > 
> > > -ml
> > 
> > I ran fw_update without any packages being updated.  Here is the output of
> > 'fw_update -i'  and a md5 sum of the vmm* files if that helps.
> > 
> > # fw_update -i
> > Installed: radeondrm-firmware-20150927 vmm-firmware-1.10.2p3
> > 
> > # md5 /etc/firmware/vmm-bios*
> > MD5 (/etc/firmware/vmm-bios) = 2946eaf040aa4fd31c13edd442b36665
> > MD5 (/etc/firmware/vmm-bios-license) = 4bb44edd8d967f805ae4df6386c59aaa
> > 
> >
> 
> I'm the other FX-4100 owner, I think Mike wanted you to test if BIOS
> boots work for you, for me I get SeaBIOS and boot(8) out, but crashes
> and restarts the VM as soon as it loads the kernel.
> 
> For BIOS boots, you simply don't need to pass a kernel image via
> -b or boot, just a disk image with a valid boot sector.
> 
> -Bryan.
> 

So Bryan and I have made a little progress here, we've made it past this error
by disabling NX in the guest (which makes no sense since the CPU supports it
and the feature is enabled properly). However, it hangs later with an interrupt
issue.

Still looking at it. Looks like this cpu is the problem child model of AMD.

-ml

Re: vmctl start missing disk

[Mike Larkin]

On Mon, Jun 12, 2017 at 09:24:44PM -0700, jan wrote:
> That's true,
> 
> there should be a proper error message in the future.
> 
> I came across the same error when starting a new VM. My problem was, that I
> already used all 4 default taps that where generated by the installer (tap0,
> tap1, tap2, tap3).
> 
> So I created a new tap device file and everything worked again:
> 
> /cd /dev; sh MAKEDEV tap4/
> 
> Then you can create a new tap device for each new VM that you start.
> 
> For more details see here (I tried to create a virtual network where each VM
> responds to specific subdomain requests):
> http://blog.hermes-technology.de/openbsd/server/virtualmachine/network/2017/06/12/vmd-for-a-virtual-server-network.html#create-a-raw-disk-file-and-start-the-installation
> 
>   
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://openbsd-archive.7691.n7.nabble.com/vmctl-start-missing-disk-tp319604p320576.html
> Sent from the openbsd dev - bugs mailing list archive at Nabble.com.
>

Jan,

Great page you wrote there. It's nice to know people are starting to use this.

-ml

Re: VMM on BIOS becomes unusable

[Mike Larkin]

On Tue, Sep 26, 2017 at 01:19:04PM -0400, Daniel Wilkins wrote:
> On Tue, Sep 26, 2017 at 02:21:34AM -0700, Mike Larkin wrote:
> > On Tue, Sep 26, 2017 at 01:26:47AM -0400, Daniel Wilkins wrote:
> > > On Mon, Sep 25, 2017 at 10:16:21PM -0700, Mike Larkin wrote:
> > > > Please define "enough times".
> > > > 
> > > > -ml
> > > 
> > > Sadly it's not consistent. I think I got to 7 boots this time today or so;
> > > 5-10 seems like a good estimate to me. Pretty sure I've had it happen 
> > > after 3
> > > boots, think I got to 11 or 12 once. Since I don't recall whether I 
> > > brought
> > > it up on the original email the OS is irrelevant as far as I can tell, 
> > > I've
> > > had Linux trigger it, had OpenBSD trigger it, had Plan9 trigger it, I 
> > > think
> > > I triggered it once when I was seeing if I could get a DOS running in 
> > > there.
> > > 
> > 
> > Please provide your vm.conf or equivalent vmctl start command line, and the
> > vmd -dv log output (pkill -9 vmd && vmd -dv   and then vmctl log verbose)
> > when the issue occurs.
> > 
> > -ml
> > 
> 
> I've attached vm.conf (whether or not I have it is irrelevant though) and a 
> script
> session with the commands asked to make sure I didn't miss anything. The 
> vmctl start
> was the most minimal that triggers it, which is literally just "put it on an 
> image that
> wants a bios". vmd.log looks like the vm stuff somehow gets into a state 
> where an interrupt
> is messed up that seabios triggers?

> startup
> vm_opentty: vm lottie tty /dev/ttyp5 uid 0 gid 4 mode 620
> lottie: started vm 12 successfully, tty /dev/ttyp5
> loadfile_bios: loaded BIOS image
> run_vm: initializing hardware for vm lottie
> run_vm: starting vcpu threads for vm lottie
> vcpu_reset: resetting vcpu 0 for vm 12
> run_vm: waiting on events for VM lottie
> i8259_write_datareg: master pic, reset IRQ vector to 0x8
> i8259_write_datareg: slave pic, reset IRQ vector to 0x70
> virtio_blk_io: device reset
> i8259_nonspecific_eoi: master pic nonspecific eoi not supported

> Script started on Tue Sep 26 13:11:04 2017
> # pkill -9 vmd
> # cd lottie
> # 
# vmd -dv 2> vmd.log  &
> [1] 98067
> # vmctl log verbose
> # vmctl start lottie -d lottie.img
>   
>   
>   
> 
>  
# vmctl start lottie -d lottie.img  -c
> vmctl: starting without network interfaces
> Connected to /dev/ttyp5 (speed 9600)
> Changing serial settings was 0/0 now 3/0
> SeaBIOS (version 1.10.2p2-OpenBSD-vmm)

This is slightly downlevel. Probably not the issue but you might want to
fw_update anyway.

IIRC your machine is a Westmere. I have one of those too and I ran through
about 20 or 30 vmm+seabios boots just now without any problem. I'm wondering
if it's a leak of some sort, since my machine has more memory than yours.

Do you get more boots if you reduce the memory on each vmm boot to 128MB or
256MB?

-ml

> BUILD: gcc: (GCC) 4.2.1 20070719  binutils: 2.17
> enabling shadow ram
> Unable to unlock ram - bridge not found
> RamSize: 0x2000 [cmos]
> malloc preinit
> malloc init
> init ivt
> init bda
> init bios32
> init keyboard
> init pic
> math cp init
> pci setup
> === PCI bus & bridge init ===
> PCI: pci_bios_init_bus_rec bus = 0x0
> === PCI device probing ===
> PCI probe
> Found 4 PCI devices (max PCI bus is 00)
> === PCI new allocation pass #1 ===
> PCI: check devices
> === PCI new allocation pass #2 ===
> PCI: IO: c000 - efff
> PCI: 32: 2000 - fec0
> PCI: map device bdf=00:01.0  bar 0, addr c000, size 1000 [io]
> PCI: map device bdf=00:02.0  bar 0, addr d000, size 1000 [io]
> PCI: map device bdf=00:03.0  bar 0, addr e000, size 1000 [io]
> PCI: map device bdf=00:00.0  bar 6, addr febfc000, size 1000 [mem]
> PCI: map device bdf=00:01.0  bar 6, addr febfd000, size 1000 [mem]
> PCI: map device bdf=00:02.0  bar 6, addr febfe000, size 1000 [mem]
> PCI: map device bdf=00:03.0  bar 6, addr febff000, size 1000 [mem]
> PCI: init bdf=00:00.0 id=0b5d:0666
> PCI: init bdf=00:01.0 id=1af4:1005
> PCI: init bdf=00:02.0 id=1af4:1001
> PCI: init bdf=00:03.0 id

Re: VMM on BIOS becomes unusable

[Mike Larkin]

On Tue, Sep 26, 2017 at 01:26:47AM -0400, Daniel Wilkins wrote:
> On Mon, Sep 25, 2017 at 10:16:21PM -0700, Mike Larkin wrote:
> > Please define "enough times".
> > 
> > -ml
> 
> Sadly it's not consistent. I think I got to 7 boots this time today or so;
> 5-10 seems like a good estimate to me. Pretty sure I've had it happen after 3
> boots, think I got to 11 or 12 once. Since I don't recall whether I brought
> it up on the original email the OS is irrelevant as far as I can tell, I've
> had Linux trigger it, had OpenBSD trigger it, had Plan9 trigger it, I think
> I triggered it once when I was seeing if I could get a DOS running in there.
> 

Please provide your vm.conf or equivalent vmctl start command line, and the
vmd -dv log output (pkill -9 vmd && vmd -dv   and then vmctl log verbose)
when the issue occurs.

-ml

Re: Reboot (dounmount) crash with latest kernel on amd64

[Mike Larkin]

On Tue, Dec 12, 2017 at 04:33:41PM +0100, Grégoire Jadi wrote:
> >Synopsis:Reboot (dounmount) crash with latest kernel on amd64
> >Category:kernel amd64
> >Environment:
>   System  : OpenBSD 6.2
>   Details : OpenBSD 6.2-current (GENERIC.MP) #1: Tue Dec 12 15:51:42 
> CET 2017
>
> daimrod@puffy:/home/daimrod/src/openbsd/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> I compiled the latest version of the kernel from CVS to try stsp@ patch on 
> ieee80211_node_checkrssi and rebooted several times.
> Everytime I rebooted my computer dounmount crashed.
> 
> Sorry I was a bit tired of copying the addresses so I replaced them with
> "...". Since it happens everytime I can provide them if needed.
> 
> Here is the trace/ps/show reg :
> 
> syncing disks... done
> kernel: protection fault trap, code=0
> Stopped atdounmount+0x35: movq0x28(%r13), %rax
> 
> ddb{0}> trace
> dounmount(800032c77890,ff0118c43190,400) at dounmount+0x35
> vop_generic_revoke(1f) at vop_generic_revoke+0x65
> VOP_REVOKE(2e2303f764c92ff3,1) at VOP_REVOKE+0x31
> vdevgone(...,10,4,1f) at vdevgone+0x8a
> disk_gone(...,...) at disk_gone+0x53
> sddetach(1,...) at sddetach+0x2a
> config_detach(...,...) at config_detach+0x14c
> scsi_detach_lun(0,...,...,...) at scsi_detach_lun+0xa8
> sr_discipline_shutdown(370,...) at sr_discipline_shutdown+0x10e
> sr_shutdown() at sr_shutdown+0x2a
> boot(2) at boot+0x59
> reboot(...) at reboot+0x4f
> sys_reboot(...,...,...) at sys_reboot+0x5c
> syscall() at syscall+0x279
> --- syscall (number 55) ---
> end of kernel
> end trace frame: 0x7f7c5980, count: -15
> 0x10922110151a:
> ddb{0}> ps
> FLAGS WAITCOMMAND
> 0x3   reboot
> [skipped]
> 

This is a known issue in recent snapshots/builds. It is being actively worked
on by a few of us, but thanks for the report.

-ml

> ddb{0}> show reg
> rdi   0x8034e000
> rsi   0x808   __kernel_end_phys+0x648
> rbp   0x800032c83810
> rbx   0x800032c77890
> rdx   0x800032c77890
> rcx   0
> rax   0
> r80x818addd0  rw_ops+0x10
> r90x8034e040
> r10   0x21
> r11   0x2
> r12   0x808   __kernel_end_phys+0x648
> r13   0xdead4110
> r14   0x8034e000
> r15   0x800032c77890
> rip   0x8113fe75  dounmount+0x35
> cs0x8
> rflags0x10286 __ALIGN_SIZE+0xf286
> rsp   0x800032c837e0
> ss0x10
> dounmount+0x35:   movq0x28(%r13),%rax
> ddb{0}> 
> 
> 
> >How-To-Repeat:
> # reboot
> 
> >Fix:
> No idea
> 
> 
> dmesg:
> OpenBSD 6.2-current (GENERIC.MP) #1: Tue Dec 12 15:51:42 CET 2017
> 
> daimrod@puffy:/home/daimrod/src/openbsd/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4062691328 (3874MB)
> avail mem = 3932639232 (3750MB)
> 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 "6QET47WW (1.17 )" date 07/14/2010
> bios0: LENOVO 3680BA5
> 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 
> DMAR SSDT SSDT 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 520 @ 2.40GHz, 2660.49 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 2393996550 Hz
> 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 520 @ 2.40GHz, 2660.00 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> 

Re: vmd: owner feature and vms started as root

[Mike Larkin]

On Tue, Dec 05, 2017 at 11:21:29PM -0800, Pratik Vyas wrote:
> * Aaron Bieber  [2017-12-01 15:33:25 -0700]:
> 
> > 
> > OK?
> > 
> 
> ok!
> 

ok mlarkin in case this didn't go in already

Re: possible fpu.c regression in 6.2-stable/amd64?

[Mike Larkin]

On Wed, Dec 13, 2017 at 05:27:17PM -0600, C. Turner wrote:
> 
> Hello -
> 
> I am in the process of bringing up a build VM on KVM/Linux to start
> some 6.2 upgrades - however the 6.2 release ISO did not yield a
> fully functional install on this particular VM (yes, SHA checks
> run) - there were various (ignored) CRC errors during the install
> unpacking stage as well as SIGFPE of various daemons on boot, login
> not passing through to the second step of password, etc. The iso
> was also refetched from a different mirror, etc.
> 
> The previous disk image with a stale 6.1-current did work (fpu.c
> v1.33.6.1), as well the December 11 snapshot.
> 
> I checked cvsweb and saw there had been some activity in fpu.c, so
> I booted from the snapshot, and was able to build a 6.2-current
> kernel containing the latest v1.39 of amd64/fpu.c while chrooted into the
> 6.2 disk image , which seem to run successfully (none of the boot
> errors occur and console login is successful).
> 
> Mentioning here although fixed in the snap this since it seems like
> it might be worth reporting.  The host processor is an AMD FX-8320E
> running KVM (perhaps why it hasn't been reported yet ;), dmesg from
> the backported 6.2 boot is attached- let me know if I can provide
> or test anything else.
> 
> Thanks,
> 
> - Chris
> 


Are you saying "it's broken in 6.2-release but fixed in 6.2-current" ?

-ml

> OpenBSD 6.2-stable (GENERIC.MP) #1: Wed Dec 13 22:22:42 GMT 2017
> root@ob02.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2130538496 (2031MB)
> avail mem = 2059005952 (1963MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68c0 (12 entries)
> bios0: vendor SeaBIOS version "1.9.3-1.fc25" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: sleep states S5
> acpi0: tables DSDT FACP APIC
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Opteron 63xx class CPU, 3214.79 MHz
> 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,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,XOP,FMA4,TBM,BMI1
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 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
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Opteron 63xx class CPU, 3214.43 MHz
> cpu1: 
> 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,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,XOP,FMA4,TBM,BMI1
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Opteron 63xx class CPU, 3214.43 MHz
> cpu2: 
> 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,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,XOP,FMA4,TBM,BMI1
> cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu2: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu2: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Opteron 63xx class CPU, 3214.43 MHz
> cpu3: 
> 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,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,XOP,FMA4,TBM,BMI1
> cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
> 64b/line 16-way L2 cache
> cpu3: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu3: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpicpu2 at acpi0: C1(@1 halt!)
> acpicpu3 at acpi0: C1(@1 halt!)
> "ACPI0006" at acpi0 not configured
> "PNP0F13" at acpi0 not configured
> "PNP0700" at acpi0 not configured
> "PNP0A06" at acpi0 not 

Re: possible fpu.c regression in 6.2-stable/amd64?

[Mike Larkin]

On Thu, Dec 14, 2017 at 02:13:23AM -0600, C. Turner wrote:
> On Thu, Dec 14, 2017 at 02:10:43AM -0600, C. Turner wrote:
> > On Wed, Dec 13, 2017 at 11:30:09PM -0800, Mike Larkin wrote:
> > > Are you saying "it's broken in 6.2-release but fixed in 6.2-current" ?
> > 
> > Ah - sorry - munged branch names.
> > 
> > Yes, the 6.2-current snapshot of 12/11 works, as does the kernel
> > resulting from copying cvs-tip v1.39 fpu.c into a 6.2-stable tree and
> > building in a 6.2 release changeroot from the working 12/11 snapshot.
> 
> And also yes, the 6.2 release image does not work.
> 

Ok. Not sure if that fix is going to be backported ... But thanks for reporting
this, at least it's documented on the list now in case someone else runs into
the same problem.

-ml

Re: VMM/VMD problem - sendbug not configured

[Mike Larkin]

On Mon, Dec 18, 2017 at 06:05:01PM -0800, Greg Taylor wrote:
> From kavin...@triathlon.biodock.io Sat Dec 16 12:44:54 2017
> Return-Path: kavin...@triathlon.biodock.io
> Delivered-To: kavin...@triathlon.biodock.io
> Received: from localhost (triathlon.biodock.io [local])
> by triathlon.biodock.io (OpenSMTPD) with ESMTPA id 39de18ff;
> Sat, 16 Dec 2017 12:44:54 -0800 (PST)
> Date: Sat, 16 Dec 2017 12:44:54 -0800 (PST)
> To: bugs@openbsd.org
> Subject:
> From: kavin...@triathlon.biodock.io
> Cc: kavin...@triathlon.biodock.io
> Reply-To: greg.k.tay...@gmail.com
> Message-Id: <11a308b2b38e7...@triathlon.biodock.io>
> Status: RO
> 
> >Synopsis: i386 errors with VMM/VMD and X on Intel i7
> >Category: VMM/VMD
> >Environment:
> System  : OpenBSD 6.2
> Details : OpenBSD 6.2 (GENERIC.MP) #166: Tue Oct  3 19:58:05 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> 
> Architecture: OpenBSD.i386
> Machine : i386
> >Description:
> I attempted to configure VMM/VMD on my system.  I was able to start VMD
> and create a disk image.  Whe I attempt to connect to the virtual system
> the console output remains blank.  Further, after doing this, my browsers
> (firefox and otter-browser) started to core dump regularly.
> >How-To-Repeat:
> 1.  Install i386 version of OpenBSD 6.2 on an i7

Yeah, i386 vmm is a bit shaky at the moment.

> 2.  Start VMD using a minimal configuration
> 3.  Create a virtual disk using vmctl
> 4.  run 'vmctl start -c ...' on the disk image with wither alpine linux or
> bsd
> >Fix:
> Next, I will reinstall amd64 version of OpenBSD on my system and try again.
> 

you'll be much happier with that.

-ml

> 
> dmesg:
> OpenBSD 6.2 (GENERIC.MP) #166: Tue Oct  3 19:58:05 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz ("GenuineIntel" 686-class) 4
> GHz
> 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,NXE,PAGE1GB,LONG,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,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
> real mem  = 3714842624 (3542MB)
> avail mem = 3629563904 (3461MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 08/09/13, SMBIOS rev. 2.8 @ 0xecf30 (91 entries)
> bios0: vendor American Megatrends Inc. version "3201" date 01/24/2017
> bios0: ASUS All Series
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT SSDT SSDT SSDT MCFG HPET SSDT SSDT UEFI
> acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4)
> 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, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> 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) Core(TM) i7-4790K CPU @ 4.00GHz ("GenuineIntel" 686-class) 4
> GHz
> cpu1:
> 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,NXE,PAGE1GB,LONG,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,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz ("GenuineIntel" 686-class) 4
> GHz
> cpu2:
> 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,NXE,PAGE1GB,LONG,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,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz ("GenuineIntel" 686-class) 4
> GHz
> cpu3:
> 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,NXE,PAGE1GB,LONG,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,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,SENSOR,ARAT
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz ("GenuineIntel" 686-class) 4
> GHz
> cpu4:
> 

Re: QEMU

[Mike Larkin]

On Mon, Nov 20, 2017 at 02:42:36PM -0500, Joshua Brand wrote:
> Hello,
> 
> I'm experiencing performance issues with OpenBSD 6.1 and 6.2 when running on
> qemu 2.10 (machine type "pc-i440fx-2.10").
> 
> The symptoms are that some simple commands become quite slow or
> unresponsive. For example: "vmstat -w 1", or "iostat -w 1", and "top -s 1".
> I assume this is something related to timing within the kernel. I've tried
> compiling a "CUSTOM" kernel to change kern.clockrate "hz" from "100" to
> "1000", but this didn't eliminate the latency.
> I'm not sure if you generally support qemu, but any advice or suggestions
> would be appreciated. This behavior wasn't present when running OpenBSD 6.1
> or 6.2 with previous versions of qemu 2.x.
> 
> Below are the steps taken to reproduce this issue:
> 
> 1. Install qemu on a host server.
> 2. Create a VM with hardware type "pc-i440fx-2.10".
> 3. Install OpenBSD from the "install61.iso" or "install62.iso"
> 
> Let me know if you require any additional information.
> 

What is the host system?

> Thanks,
> 
> -- 
> Joshua Brand
> Systems Administrator
> 

Re: Sudden reboot after resuming from hibernation

[Mike Larkin]

On Fri, Nov 03, 2017 at 10:20:27AM +0100, Alessandro Grassi wrote:
> Hi Mike,
> 
> On Fri, Nov 3, 2017 at 9:27 AM, Mike Larkin <mlar...@azathoth.net> wrote:
> > There seems to be a lot of unrelated information here.
> 
> I thought it seemed related, sorry about that.
> 
> > Can you summarize please:
> >
> > * when does it work
> > * when does it not work
> >
> > leave out anything about freezes or gpus or unrelated stuff.
> 
> Alright. I've tried some more times, and I can say that it regularly:
> 
> * Resumes correctly from the first hibernation after a clean boot
> * Fails to resume from any second hibernation
> 
> This happens with or without the memory limitation on the bootloader.
> 
> On all my recent tests it didn't reset, but just printed the
> information I attached in the other mail and dropped a tty login when
> I pressed enter.
> 
> Regards,
> Alessandro

Thanks for settling that. Just for another data point, are you using SR
crypto, and could you please send your dmesg again? (I tossed the original
email).

-ml

Re: Sudden reboot after resuming from hibernation

[Mike Larkin]

On Mon, Nov 06, 2017 at 02:00:26PM +0100, Alessandro Grassi wrote:
> Hi Mike,
> 
> On Fri, Nov 3, 2017 at 7:18 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> > Thanks for settling that. Just for another data point, are you using SR
> > crypto, and could you please send your dmesg again? (I tossed the original
> > email).
> 
> Yes, I'm using SR crypto. dmesg attached.
> 
> Cheers

I can't see why this would fail. I just unhibernated a bunch of times in a row
with a ton of memory in use, and I didn't see any errors. Nor have I heard of
anyone else having problems on the second unhibernate.

I'm guessing this has something to do with coreboot, since that seems to be
the only large difference in play here. If you can find another machine that's 
the same model as yours w/o coreboot, and it still fails, let me know and I'll
dig further. But I tossed out all my hardware from this era a while ago.

-ml

> OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
> 
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4004110336 (3818MB)
> avail mem = 3875733504 (3696MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbfaa0020 (8 entries)
> bios0: vendor coreboot version "CBET4000 3774c98" date 09/07/2016
> bios0: LENOVO 7459M78
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TCPA APIC DMAR HPET
> acpi0: wakeup devices HDEF(S4) USB1(S4) USB2(S4) USB3(S4) EHC1(S4) USB4(S4) 
> USB5(S4) USB6(S4) EHC2(S4) SLT1(S4) SLT2(S4) SLT3(S4) SLT6(S4) LANC(S3) 
> LANR(S3) SLPB(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xf000, bus 0-63
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz, 1600.34 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 3MB 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 266MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz, 1600.06 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 3MB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEGP)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus 2 (RP02)
> acpiprt4 at acpi0: bus 3 (RP03)
> acpiprt5 at acpi0: bus 4 (RP04)
> acpiprt6 at acpi0: bus -1 (RP05)
> acpiprt7 at acpi0: bus -1 (RP06)
> acpiprt8 at acpi0: bus 5 (PCIB)
> acpiec0 at acpi0
> acpicpu0 at acpi0
> C1: bogo buffer
> C2: bogo buffer
> C3: bogo buffer: C1(@1 halt!), PSS
> acpicpu1 at acpi0
> C1: bogo buffer
> C2: bogo buffer
> C3: bogo buffer: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 99 degC
> acpithinkpad0 at acpi0
> acpiac0 at acpi0: AC unit offline
> acpibat0 at acpi0: BAT0 model "42T4650" serial   784 type LION oem "Panasonic"
> acpibat1 at acpi0: BAT1 not present
> acpibtn0 at acpi0: SLPB
> acpibtn1 at acpi0: LID_
> "PNP0F13" at acpi0 not configured
> "WACF004" at acpi0 not configured
> acpidock0 at acpi0: DOCK not docked (0)
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: LCD0
> cpu0: Enhanced SpeedStep 1600 MHz: speeds: 2401, 2400, 1600, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
> inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: msi
> inteldrm0: 848x480, 32bpp
> error: [drm:pid0:intel_pipe_config_compare] *ERROR* mismatch in 
> base.adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 0, found 1)
> error: [drm:pid0:intel_pipe_config_compare] *ERROR* mismatch in 
> base.adjusted_mode.flags(DRM_MODE_FLAG_PVSYNC) (expected 0, found 4)
> pipe state doesn't match!
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> wsdispl

Re: OpenBSD 6.x unable to boot from Mac mini 2014

[Mike Larkin]

On Mon, Oct 30, 2017 at 06:31:19PM +0100, Kristian Peters wrote:
> Hi,
> 
> As I thought, a simple addition to acpi/dsdt.c and the Mac mini is able
> to boot. I used the external hard drive from a fresh 6.2-install on
> another computer to that purpose. This patch is tested (tried to compile
> the release under the newly built kernel) and was made against 6.2-release.
> 
> I attach the patch and the dmesg-output of the Mac mini running with the
> patched kernel.
> 
> Can you merge it in -current?
> 
> --- 6.2/src/sys/dev/acpi/dsdt.c Sun May 28 17:36:45 2017
> +++ src/sys/dev/acpi/dsdt.c Mon Oct 30 16:08:39 2017
> @@ -2488,6 +2488,11 @@
> aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
> val, mode, fld->v_field.flags);
> break;
> +   case ACPI_OPREG_CMOS:
> +   printf("RegionSpace: %u\n",
> ref1->v_opregion.iospace);
> +   aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
> +   val, mode, fld->v_field.flags);
> +   break;
> default:
> aml_die("Unsupported RegionSpace 0x%x",
> ref1->v_opregion.iospace);
> 
> PS: I still fail to build the full release and, thus, also the
> install62.fs image I want to use for installation. So it would be great
> if you consider fixing the issue soon.
> 
> Best wishes, *Kristian
> 

I don't think this is right. It may be "solving" your problem but our rwgas
implementation doesn't handle this type of OpRegion. So, at best, we're ignoring
the request (with the changes above), or worse, perhaps trashing some memory.

Someone needs to add the I/O for this type of region (CMOS NVRAM) to
the gasio code in acpi.c. There is a sequence of IN/OUT instructions that need 
to
occur (in a proper order, with correct locking because the OS is using the
device also) to get at those NVRAM registers. It probably isn't a huge amount
of work, but nobody has stepped up to do it yet.

If you want a workaround, you might try just ignoring ACPI_OPREG_CMOS locally
in your tree. That too isn't right but at least it won't be possibly causing
side effects/damage elsewhere.

-ml

Re: Sudden reboot after resuming from hibernation

[Mike Larkin]

On Tue, Oct 31, 2017 at 05:34:10PM +0100, Alessandro Grassi wrote:
> Hi Mike,
> 
> On Tue, Oct 31, 2017 at 5:18 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> >> >How-To-Repeat:
> >>   - Hibernate ($ ZZZ)
> >>   - Resume
> >
> > Did this ever work or was this the first time you tried?
> 
> I tried a bunch of times since installation, I have a vague memory of
> it working once or twice.
> 
> Definitely not recently though.
> 
> Regards,
> Alessandro

Can you send me the output of "machine memory" at the boot> prompt please?

-ml

Re: Sudden reboot after resuming from hibernation

[Mike Larkin]

On Tue, Oct 31, 2017 at 08:47:50AM +0100, Alessandro Grassi wrote:
> >Synopsis:Sudden reboot after resuming from hibernation
> >Category:system
> >Environment:
>   System  : OpenBSD 6.2
>   Details : OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
>
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After hibernating (ZZZ), the bootloader correctly recognises the 
> hibernation and resumes for it.
>   However most of the times a few seconds after it's done resuming and X 
> pops back, the computer is rebooted/reset.
> 
>   Not sure how relevant, but:
> - I run a Thinkpad X200 with libreboot
> - I'm using FDE (swap is on the same physicla disk as root, standard 
> installation)
> - I dual boot with Linux
> - The bootloader is started by chainloading seabios from libreboot, 
> which then chainloads MBR
> - The system is otherwise functional, except for X hanging sometimes 
> when using compton
> - No dumps found in /var/crash
> 
> >How-To-Repeat:
>   - Hibernate ($ ZZZ)
>   - Resume
> 
> 

Did this ever work or was this the first time you tried?

-ml

> dmesg:
> OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
> 
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4004110336 (3818MB)
> avail mem = 3875741696 (3696MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbfaa0020 (8 entries)
> bios0: vendor coreboot version "CBET4000 3774c98" date 09/07/2016
> bios0: LENOVO 7459M78
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TCPA APIC DMAR HPET
> acpi0: wakeup devices HDEF(S4) USB1(S4) USB2(S4) USB3(S4) EHC1(S4) USB4(S4) 
> USB5(S4) USB6(S4) EHC2(S4) SLT1(S4) SLT2(S4) SLT3(S4) SLT6(S4) LANC(S3) 
> LANR(S3) SLPB(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xf000, bus 0-63
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz, 1600.28 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 3MB 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 266MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz, 1600.06 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 3MB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEGP)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus 2 (RP02)
> acpiprt4 at acpi0: bus 3 (RP03)
> acpiprt5 at acpi0: bus 4 (RP04)
> acpiprt6 at acpi0: bus -1 (RP05)
> acpiprt7 at acpi0: bus -1 (RP06)
> acpiprt8 at acpi0: bus 5 (PCIB)
> acpiec0 at acpi0
> acpicpu0 at acpi0
> C1: bogo buffer
> C2: bogo buffer
> C3: bogo buffer: C1(@1 halt!), PSS
> acpicpu1 at acpi0
> C1: bogo buffer
> C2: bogo buffer
> C3: bogo buffer: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 99 degC
> acpithinkpad0 at acpi0
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model "42T4650" serial   784 type LION oem "Panasonic"
> acpibat1 at acpi0: BAT1 not present
> acpibtn0 at acpi0: SLPB
> acpibtn1 at acpi0: LID_
> "PNP0F13" at acpi0 not configured
> "WACF004" at acpi0 not configured
> acpidock0 at acpi0: DOCK not docked (0)
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: LCD0
> cpu0: Enhanced SpeedStep 1600 MHz: speeds: 2401, 2400, 1600, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
> inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: msi
> inteldrm0: 848x480, 32bpp
> error: [drm:pid0:intel_pipe_config_compare] *ERROR* mismatch in 
> base.adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 0, found 1)
> error: [drm:pid0:intel_pipe_config_compare] *ERROR* mismatch in 
> base.adjusted_mode.flags(DRM_MODE_FLAG_PVSYNC) (expected 0, found 4)
> pipe state doesn't match!
> wsdisplay0 at inteldrm0 mux 1: 

Re: Sudden reboot after resuming from hibernation

[Mike Larkin]

On Tue, Oct 31, 2017 at 09:04:59PM +0100, Alessandro Grassi wrote:
> Hi Mike,
> 
> On Tue, Oct 31, 2017 at 5:34 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> > Can you send me the output of "machine memory" at the boot> prompt please?
> 
> Here you go:
> 
> Region 0: type 1 at 0x0 for 639KB
> Region 1: type 2 at 0x9fc00 for 1KB
> Region 2: type 2 at 0xf for 64KB
> Region 3: type 1 at 0x10 for 3139192KB
> Region 4: type 2 at 0xbfa9e000 for 267656KB
> Region 5: type 2 at 0xf000 for 65536KB
> Region 6: type 1 at 0x1 for 786432KB
> Low ram: 639KB  High ram: 3139192KB
> Total free memory: 3926263KB
> 
> Regards,
> Alessandro

Those regions look ok.

Can you try a small test:

1. on next boot> , type:
  mach mem =256M

2. then 'boot'

3. ZZZ

4. power up the machine again and do step 1 again that time


See if that makes any difference. It's telling the kernel to only
use 256MB RAM. You need to do the same thing in step 4 after restarting
or it will think the memory size changed and skip un-hibernate.

If that doesn't work, I'd start to think it's some sort of coreboot/libreboot
thing as hibernate has been pretty stable for most machines for quite some time.
We did make a change at the recent hackathon to make things faster, but I don't
see how that would be causing this.

Also, when you unhibernate your 4GB machine as above, does it sit for some
time with a black screen after loading the hibernated image or does it instantly
restart after reading it?

-ml

Re: hang in i386 pmap_tlb_shootwait

[Mike Larkin]

On Wed, May 09, 2018 at 11:01:58AM +0200, Alexander Bluhm wrote:
> Hi,
> 
> While running my nightly regression tests, I compiled
> /ports/misc/posixtestsuite.  It was the first time that I was running
> regress while having some other load on the machine.  During
> regress/lib/libc/ieeefp/except the machine hang.  It has 2 CPUs.
> 

Based on the discussion below, it sounds like the same bug mpi and I noticed
a few weeks ago in nantes. A cpu gets stuck with interrupts disabled and a
shootdown can't happen because the IPI isn't being received by that CPU.

You might want to apply mpi's changes to see if it spins out waiting for the
lock, and where. The output of show all locks might be useful also.

-ml

> The final output of the test:
> 
> ===> ieeefp/except
> cc -O2 -pipe   -MD -MP  -c /usr/src/regress/lib/libc/ieeefp/except/except.c
> cc   -o except except.o 
> ./except fltdiv
> 
> This kernel was running:
> 
> OpenBSD 6.3-current (GENERIC.MP) #592: Mon May  7 10:07:12 MDT 2018
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> 
> I could break into ddb:
> 
> Stopped at  db_enter+0x4:   popl%ebp
> ddb{0}> trace
> db_enter() at db_enter+0x4
> comintr(d577d000) at comintr+0x21e
> intr_handler(f58be8e4,d577c840) at intr_handler+0x30
> Xintr_ioapic3_untramp() at Xintr_ioapic3_untramp+0xd7
> --- interrupt ---
> pmap_tlb_shootwait() at pmap_tlb_shootwait+0x12
> pmap_do_remove_pae(d0d33ce0,f55f2000,f55f3000,0) at pmap_do_remove_pae+0x2ac
> pmap_remove(d0d33ce0,f55f2000,f55f3000) at pmap_remove+0x18
> uvm_unmap_kill_entry(d0d2d2b4,d4c810dc) at uvm_unmap_kill_entry+0xde
> uvm_unmap_remove(d0d2d2b4,f55f2000,f55f3000,f58bea00,0,1) at 
> uvm_unmap_remove+0
> x194
> sys_kbind(d435dcf0,f58bea80,f58bea78) at sys_kbind+0x295
> syscall() at syscall+0x25e
> --- syscall (number -813868376) ---
> end of kernel
> 0x7d6558e8:
> 
> CPU 0 is running clang, CPU 1 is running the except test script.
> 
> ddb{0}> ps
>PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
>  92284  394442  70506  0  7 0x2except
> *47266  113041  37786 55  7 0x2cc
>  37786  281652  35994 55  30x10008a  pause sh
>  70506  372899  71391  0  30x10008a  pause make
>  71391  488915  75345  0  30x10008a  pause sh
>  75345  253329  29923  0  30x10008a  pause make
>  29923   89609  68217  0  30x10008a  pause sh
>  68217  294846  81420  0  30x10008a  pause make
>  51311  445816  20823  0  2   0x491perl
>  81420  149032  81906  0  30x10008a  pause sh
>  81906  389989  44981  0  30x10008a  pause make
>  24237   35914  94782  0  30x100082  piperdgzip
>  94782  375463  44981  0  30x100082  piperdpax
>  44981  114211  25893  0  30x82  piperdperl
>  25893  239558   5387  0  30x10008a  pause ksh
>   5387  100109  39691  0  30x92  selectsshd
>  65456  428886  57598  0  30x100083  kqreadtail
>  57598  364467  56435  0  30x10008b  pause ksh
>  39040  394741  84200 55  2   0x482perl
>  84200   57590  22769 55  30x10008a  pause sh
>  22769  388112  71080 55  30x10008a  pause make
>  71080  289240  55503 55  30x10008a  pause sh
>  55503  177103  20823 55  30x10008a  pause make
>  20823  473630  90353  0  30x93  wait  perl
>  35994  500360  35455 55  30x82  piperdgmake
>  35455   82895  18413 55  30x10008a  pause make
>  184139872   9766 55  30x10008a  pause sh
>   9766   29157  60819 55  30x10008a  pause make
>  60819  198028  51400 55  30x10008a  pause sh
>  51400  455284  1 55  30x10008a  pause make
>  90353  444304  56435  0  30x10008b  pause ksh
>  56435  213296  1  0  20x100480tmux
>  12943  273120  79318  0  30x100083  kqreadtmux
>  79318   90427  49332  0  30x10008b  pause ksh
>  49332  480938  39691  0  30x92  selectsshd
>  79215  221858  1  0  20x100083getty
>   5182   91398  1  0  30x100083  ttyin getty
>  68061  353121  1  0  30x100083  ttyin getty
>  61973  471346  1  0  30x100083  ttyin getty
>  58677  314567  1  0  30x100083  ttyin getty
>  26310   59684  1  0  30x100083  ttyin getty
>  2  266793  1  0  20x100498cron
>  69017  469788  1 99  30x100090  poll  sndiod
>  67250  378711  1110  30x100090  poll  sndiod
>   7419  486904  35256 95  30x100092  kqreadsmtpd
>  87223  

Re: hang in i386 pmap_tlb_shootwait

[Mike Larkin]

On Wed, May 09, 2018 at 06:21:54PM +0200, Hans-Joerg Hoexer wrote:
> Hi,
> 
> I think this fallout from using interrupt gates now.  I did not properly
> enable interrupts for dna, fpu and f00f_redirect:  Thux npxintr() tries to
> get the kernel lock with interrupts disabled.  Meanwhile the IPI for tlb
> shootdown is pending for delivery.  When the sender of the IPI is holding
> the kernel lock it will spin in pmap_tlb_shootwait() and we dead lock.
> 
> Diff below fixes dna, fpu and f00f_redirect by enabling interrupts.
> 
> (dna and fpu leave the kernel directly, thus they have to disable
> interrupts again; f00f_redirect goes through calltrap which will enable
> interrupts)
> 
> Take care,
> HJ.
> 

This makes sense, ok mlarkin.

-ml

> Index: sys/arch/i386//i386/locore.s
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
> retrieving revision 1.185
> diff -u -p -u -p -r1.185 locore.s
> --- sys/arch/i386//i386/locore.s  11 Apr 2018 15:44:08 -  1.185
> +++ sys/arch/i386//i386/locore.s  9 May 2018 15:47:51 -
> @@ -988,6 +988,7 @@ IDTVEC(dna)
>   pushl   $0  # dummy error code
>   pushl   $T_DNA
>   INTRENTRY(dna)
> + sti
>   pushl   CPUVAR(SELF)
>   call*_C_LABEL(npxdna_func)
>   addl$4,%esp
> @@ -996,6 +997,7 @@ IDTVEC(dna)
>  #ifdef DIAGNOSTIC
>   movl$0xfd,%esi
>  #endif
> + cli
>   INTRFASTEXIT
>  #else
>   ZTRAP(T_DNA)
> @@ -1015,6 +1017,7 @@ IDTVEC(prot)
>  IDTVEC(f00f_redirect)
>   pushl   $T_PAGEFLT
>   INTRENTRY(f00f_redirect)
> + sti
>   testb   $PGEX_U,TF_ERR(%esp)
>   jnz calltrap
>   movl%cr2,%eax
> @@ -1050,6 +1053,7 @@ IDTVEC(fpu)
>*/
>   subl$8,%esp /* space for tf_{err,trapno} */
>   INTRENTRY(fpu)
> + sti
>   pushl   CPL # if_ppl in intrframe
>   pushl   %esp# push address of intrframe
>   incl_C_LABEL(uvmexp)+V_TRAP
> @@ -1058,6 +1062,7 @@ IDTVEC(fpu)
>  #ifdef DIAGNOSTIC
>   movl$0xfc,%esi
>  #endif
> + cli
>   INTRFASTEXIT
>  #else
>   ZTRAP(T_ARITHTRAP)
> 

Re: 6.3 (and -snapshot): panic: aml_rwgen: unregistered RegionSpace 0x5

[Mike Larkin]

On Fri, Jun 08, 2018 at 02:31:54PM -0400, Adam Thompson wrote:
> Tested on 6.3 and -snapshot from 2018-Jun-07.
> 
> Hardware: Apple MacBook Pro 15" w/TouchBar Late 2017 (Apple model ID
> "MacBookPro14,3")
> 
> Booting via EFI firmware, from external USB drive with "install63.fs" dd'd
> to it.  (I tried different USB drives with same result.)
> 
> Picture of console : https://photos.app.goo.gl/uGHJdQurcIJTKVnE3
> 
> Transcription of console (as best I can):
> 
> ***Console start***
> acpi0 at bios0: rev 2
> acpi0: tables DSDT FACP UEFI ECDI HPET APIC MCFG SBST SSDT SSDT SSDT SSDT
> SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR VFCI
> acpiec0 at acpi0
> acpimatd0 at acpi0 addr 0xfee8: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-7700HQ CPU @ 2.88GHz, 3792.96 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBVI,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, 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
> ioapic0 at mainbus0: apid2 pa 0xfec8, version 20, 24 pins
> panic: aml_rwgen: unregistered RegionSpace 0x5
> 
> 
> The operating system has halted.
> Please press any key to reboot.
> 
> rebooting...
> ***Console end***
> 
> Some console output has likely scrolled off, not sure how to get a USB
> serial console on a MacBook Pro, sorry.
> Also FWIW, the system does not reboot and must be powered off manually.
> 
> I can re-test fairly easily, although I think I need a filesystem image to
> make the EFI (not UEFI, I think?) firmware happy.  I should be able to drop
> new kernels onto the existing USB stick on an existing OpenBSD system,
> presumably.
> 
> -Adam Thompson
>  athom...@athompso.net
> 

Fixed in -current.

Re: 6.3 (and -snapshot): panic: aml_rwgen: unregistered RegionSpace 0x5

[Mike Larkin]

On Tue, Jun 12, 2018 at 12:54:07PM -0500, Adam Thompson wrote:
> On 2018-06-12 02:11, Mike Larkin wrote:
> > Fixed in -current.
> 
> That was fast.  Thank you.
> 
> So, if I try a -snapshot build, say, next week, I should get past that part,
> right?  I'm not sure how often -snapshot gets rebuilt right now.
> 
> (Although probably just to the next error message, I don't have any
> illusions about OpenBSD running properly on this thing yet.)
> 
> -Adam
> 

It runs fine.

There are a few missing bits but it's mostly usable. Ask patrick@ for a diff
to make the wireless work.

-ml

Re: VMM owner needs to be part of wheel

[Mike Larkin]

On Mon, Jun 18, 2018 at 12:05:43AM +0200, Reyk Floeter wrote:
> Hi,
> 
> changing the umask in control.c could fix it. There’s no need to restrict it 
> to wheel since vmd checks the permissions based on configuration internally. 
> Having the vmd socket world-writable should be OK.
> 
> But we could eventually use a group _vmd to shield off users who shouldn’t 
> even be able to do anything. But this doesn’t make much sense - it would be a 
> bit like restricting users from running ps a.
> 
> I can make a diff tomorrow.
> 
> Reyk
> 

Thanks Reyk! I'm sure you will come up with the right solution.

-ml

> Am 17.06.2018 um 22:35 schrieb obs...@high5.nl:
> 
> >> Synopsis:VMM owner needs to be part of group wheel in order to run 
> >> vmctl console|start|stop
> >> Category:system
> >> Environment:
> >System  : OpenBSD 6.3
> >Details : OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018
> > 
> > r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> >Architecture: OpenBSD.amd64
> >Machine : amd64
> >> Description:
> >When some level of vmctl is needed for users they are currently required 
> > to be part of group wheel. It would be great from a hosting perspective to 
> > allow users to control their own VM and attach to tJhe console. I started a 
> > small project to host OpenBSD VMs for the community out of Amsterdam and I 
> > would love to provide users access to their own VM.
> >> How-To-Repeat:
> >Set the owner who is not in wheel will result in a message like:
> >vmctl: command failed: Operation not permitted
> >> Fix:
> >The current work around is to add the user to group wheel, which is 
> > might be ok for trusted users.
> > 
> > 
> > dmesg:
> > OpenBSD 6.3 (GENERIC.MP) #3: Fri May 18 00:06:26 CEST 2018
> >
> > r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 8544342016 (8148MB)
> > avail mem = 8278310912 (7894MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9750 (56 entries)
> > bios0: vendor American Megatrends Inc. version "2.0b" date 09/17/2012
> > bios0: Supermicro X9SCL/X9SCM
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S1 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SPMI SSDT SSDT EINJ ERST 
> > HEST BERT BGRT
> > acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) 
> > USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) 
> > PXSX(S4) RP02(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) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3100.45 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu0: 256KB 64b/line 8-way L2 cache
> > acpitimer0: recalibrated TSC frequency 3100015637 Hz
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 100MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3100.03 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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-1220 V2 @ 3.10GHz, 3100.03 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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-1220 V2 @ 3.10GHz, 3100.03 MHz
> > cpu3: 
> > 

Re: 6.3 (and -snapshot): panic: aml_rwgen: unregistered RegionSpace 0x5

[Mike Larkin]

On Sun, Jun 10, 2018 at 02:15:18PM +0200, Paul de Weerd wrote:
> I'm getting the same panic after upgrading my GPD Win to -current.
> bsd.rd still boots fine, but bsd.mp gives
> 
> panic: aml_rwgen: unregistered RegionSpace 0x8f
> 
> After that, there's a stack trace and then I get dumped in ddb.  The
> keyboard doesn't work in ddb (and the machine is tiny, doesn't have
> serial console).  However, the panic happens shortly after attaching
> sdhc2 at acpi0 (doesn't mean too much, I know).
> 
> Previous dmesg (kernel built from then-current sources plus local
> diffs to rotate the clock in the other direction and to enable bwfm)
> included below.
> 
> The keyboard is a pain to work with, which slows down testing old
> kernels to try to figure out when this was introduced.  I'll follow up
> when I know more...
> 
> Paul

I have a fix for this that I'll commit tonight. Been sitting in my tree
for a while now.

-ml

Re: VMs "crash" with: vcpu_run_loop: vm 19 / vcpu 0 run ioctl failed: Invalid argument

[Mike Larkin]

On Tue, Jun 19, 2018 at 03:42:06PM +0200, obs...@high5.nl wrote:
> >Synopsis:VMs stop intermitently after vcpu_run_loop error
> >Category:system
> >Environment:
>   System  : OpenBSD 6.3
>   Details : OpenBSD 6.3 (GENERIC.MP) #4: Sun Jun 17 11:22:20 CEST 2018
>
> r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   Currently running 12 VMs on a single machine. After some random time, 
> VMs randomly shutdown. Sometimes a single VM and sometimes more. It's always 
> after an error message like the following a VM stops.
> Jun 19 11:16:49 j5 vmd[59907]: vcpu_run_loop: vm 11 / vcpu 0 run ioctl 
> failed: Invalid argument
> Jun 19 11:16:49 j5 vmd[51030]: vcpu_run_loop: vm 6 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[64667]: vcpu_run_loop: vm 9 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[53125]: vcpu_run_loop: vm 10 / vcpu 0 run ioctl 
> failed: Invalid argument
> Jun 19 11:16:49 j5 vmd[61348]: vcpu_run_loop: vm 7 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[59411]: vcpu_run_loop: vm 4 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[52083]: vcpu_run_loop: vm 12 / vcpu 0 run ioctl 
> failed: Invalid argument
> Jun 19 11:16:49 j5 vmd[21423]: vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[40185]: vcpu_run_loop: vm 5 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[60512]: vcpu_run_loop: vm 8 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[44187]: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:16:49 j5 vmd[46728]: vcpu_run_loop: vm 2 / vcpu 0 run ioctl failed: 
> Invalid argument
> Jun 19 11:20:30 j5 vmd[81571]: vmd: vm 22 event thread exited unexpectedly
>  

This is almost surely the following bug, fixed in April (log from pmap.c):

revision 1.113
date: 2018/04/17 06:31:55;  author: mlarkin;  state: Exp;  lines: +275 -64;  
commitid: BaLjO2NVfYaZP00l;
Better way of allocating EPT entries.

Don't use the standard pmap PTE functions to manipulate EPT PTEs. This
occasionally caused VMs to fail after random amounts of time due to
loading the pmap on the CPU and the processor updating A/D bits (which
are reserved bits in EPT). This ultimately manifested itself as errors
from vmd ("vcpu X run ioctl failed".)

tested by many, on different types of HW, no regressions noted


---

Can you try -current and see if you can still reproduce this problem?

> 
> Side note: after a reboot of the host, all VMs stop at one point as it looks 
> like VMM starts all the VMs at the same time. Looks like it's draining 
> resources at that point.
> 

Yes, this is a known issue, I've had it on my to-do list to have some sort
of sequencing or delay, but never got around to it (Hint, hint, such a fix would
likely be an easy intro-to-vmd-hacking effort for someone who wanted to dip 
their
toe in the water).

-ml

> >How-To-Repeat:
>   Unfortunately I have not found a way to reproduce this, I thought I was 
> on to something when I loaded a Alpine Linux VM as well, but this is now also 
> happening without it running. 
> 
> >Fix:
>   No fix.
> 
> 
> dmesg:
> OpenBSD 6.3 (GENERIC.MP) #4: Sun Jun 17 11:22:20 CEST 2018
> 
> r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8544342016 (8148MB)
> avail mem = 8278315008 (7894MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9750 (56 entries)
> bios0: vendor American Megatrends Inc. version "2.0b" date 09/17/2012
> bios0: Supermicro X9SCL/X9SCM
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SPMI SSDT SSDT EINJ ERST 
> HEST BERT BGRT
> acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) 
> USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) 
> PXSX(S4) RP02(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) Xeon(R) CPU E3-1220 V2 @ 3.10GHz, 3100.48 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 3100030275 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, 

Re: bsd.mp hits witness panic under vmm (single CPU)

[Mike Larkin]

On Thu, Jun 07, 2018 at 05:13:06PM -0700, Philip Guenther wrote:
> 
> The GENERIC bsd kernel is happy under vmm, but booting a GENERIC.MP kernel 
> hits a witness panic.  I suspect some "one CPU only" optimization is 
> resulting in the witness code being misinformed.
> 
> Here's the boot output in the vmm console.  (Yes, the userland is out of 
> date, but that shouldn't lead to a witness panic either.)
> 
> 
> (The weird "show witness" output for scsi_base.c mutexes is because 
> they're on the stack and need to be unlinked from witness before 
> returning; that *might* be causing the problem here, but I doubt it.  I'm 
> starting on a diff for that part...)
> 
> 
> Philip Guenther
> 

Is this a panic inside the guest in vmm, or is this the host panicing when
you're doing something while a VM is running in vmm on that host?

Can't really tell from the trace here...

-ml

> ---
> 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.OpenBSD.org
> 
> OpenBSD 6.3-current (GENERIC.MP) #25: Thu Jun  7 16:29:55 PDT 2018
> 
> guenther@morgaine.local:/usr/src/sys-realclean/arch/amd64/compile/GENERIC.MP
> real mem = 520093696 (496MB)
> avail mem = 485457920 (462MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0
> acpi at bios0 not configured
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.54 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,RDSEED,ADX,SMAP,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> pvbus0 at mainbus0: OpenBSD
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00
> virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
> viornd0 at virtio0
> virtio0: irq 3
> virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio1
> scsibus1 at vioblk0: 2 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 4096MB, 512 bytes/sector, 8388608 sectors
> virtio1: irq 5
> virtio2 at pci0 dev 3 function 0 "OpenBSD VMM Control" rev 0x00
> vmmci0 at virtio2
> virtio2: irq 6
> isa0 at mainbus0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo
> com0: console
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on sd0a (0084d990f4e53393.a) swap on sd0b dump on sd0b
> Automatic boot in progress: starting file system checks.
> /dev/sd0a (0084d990f4e53393.a): file system is clean; not checking
> /dev/sd0e (0084d990f4e53393.e): file system is clean; not checking
> /dev/sd0d (0084d990f4e53393.d): file system is clean; not checking
> setting tty flags
> pfctl: pfctl_rules
> pfctl: DIOCXROLLBACK: Invalid argument
> pf enabled
> starting network
> pfctl: pfctl_rules
> pfctl: DIOCXROLLBACK: Invalid argument
> reordering libraries:panic: acquiring blockable sleep lock with spinlock or 
> critical section held (kernel_lock) _lock @ 
> /usr/src/sys-realclean/arch/amd64/amd64/intr.c:525
> Stopped at  db_enter+0x5:   popq%rbp
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *522028  67277  0 0x14000  0x2000  reaper
> db_enter() at db_enter+0x5
> panic() at panic+0x138
> witness_checkorder(81b7c59c,20d,0,81cf7ca0,8002af00) 
> at
>  witness_checkorder+0xd32
> ___mp_lock(8002af00,8e0eaca0,81bdaff0) at 
> ___mp_lock+0x
> 70
> intr_handler(1,8002ae80) at intr_handler+0x40
> Xintr_legacy8_untramp(8e0ead60,81d16c60,c,10,8e0ead30,f
> fff814562c0) at Xintr_legacy8_untramp+0x155
> Xspllower(0,282,818c9e53,1ca9c,ff000257,10) at Xspllower+0xc
> uvm_pmr_freepages(1f12000,ff001f75e380) at uvm_pmr_freepages+0x204
> pmap_do_remove(ff001bd30a18,ff001f75f5a0,8e0ab4d0,81053
> c20) at pmap_do_remove+0x463
> uvm_map_teardown(0) at uvm_map_teardown+0x143
> uvmspace_free(8e0f9148) at uvmspace_free+0x36
> uvm_exit(8e0f9148) at uvm_exit+0x16
> reaper() at reaper+0x156
> end trace frame: 0x0, count: 2
> 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{0}>
> ddb{0}> show locks
> exclusive mutex  r = 0 (0x81d1bcc0) locked @ 
> /usr/src/sy
> s-realclean/uvm/uvm_pmemrange.c:1124
> ddb{0}> show witness
> Sleep locks:
> sysctllk (type: rwlock, depth: 0) -- last acquired @ 
> /usr/src/sys-realclean/ker
> n/kern_sysctl.c:233
>  >lock (type: rwlock, depth: 2) -- last acquired @ 
> /usr/src/sys-realclean/
> uvm/uvm_map.c:1936
>  netlock (type: 

Re: bsd.mp hits witness panic under vmm (single CPU)

[Mike Larkin]

On Thu, Jun 07, 2018 at 07:22:23PM -0700, Philip Guenther wrote:
> On Thu, 7 Jun 2018, Mike Larkin wrote:
> > Is this a panic inside the guest in vmm, or is this the host panicing when
> > you're doing something while a VM is running in vmm on that host?
> > 
> > Can't really tell from the trace here...
> 
> This was a guest panicing.  visa@ thinks this is the same intr_legacy8 
> panic as reported previously.
> 

Could be!

Re: VMs not booting (was: How to build with VMM_DEBUG)

[Mike Larkin]

On Fri, Jun 29, 2018 at 10:39:03AM -0700, Philip Guenther wrote:
> On Fri, 29 Jun 2018, Ax0n wrote:
> > Updated and recompiled. Here's what it's doing now. No idea what the Lock
> > Order Reversal noise is between the two VM starts, but I've seen a lot of
> > it on this laptop lately, even without using vmm. Probably unrelated.
> 
> Yep, that's from the WITNESS work and not part of the xcr0 problem.
> 
> 
> > vmm_fpurestore: guest attempted to set invalid bits in xcr0 (guest
> > %xcr0=0x1, host mask=0x)
> 
> Oh, duh: this box doesn't have XSAVE at all but we init guests as if it 
> does.  Try this diff on the host.
> 
> Philip Guenther
> 
> Index: amd64/vmm.c
> ===
> RCS file: /data/src/openbsd/src/sys/arch/amd64/amd64/vmm.c,v
> retrieving revision 1.202
> diff -u -p -r1.202 vmm.c
> --- amd64/vmm.c   22 Jun 2018 05:21:45 -  1.202
> +++ amd64/vmm.c   29 Jun 2018 17:36:34 -
> @@ -1971,7 +1971,7 @@ vcpu_reset_regs_svm(struct vcpu *vcpu, s
>   ret = vcpu_writeregs_svm(vcpu, VM_RWREGS_ALL, vrs);
>  
>   /* xcr0 power on default sets bit 0 (x87 state) */
> - vcpu->vc_gueststate.vg_xcr0 = XCR0_X87;
> + vcpu->vc_gueststate.vg_xcr0 = XCR0_X87 & xsave_mask;
>  
>  exit:
>   return ret;
> @@ -2764,7 +2764,7 @@ vcpu_reset_regs_vmx(struct vcpu *vcpu, s
>   /* XXX CR4 shadow */
>  
>   /* xcr0 power on default sets bit 0 (x87 state) */
> - vcpu->vc_gueststate.vg_xcr0 = XCR0_X87;
> + vcpu->vc_gueststate.vg_xcr0 = XCR0_X87 & xsave_mask;
>  
>   /* Flush the VMCS */
>   if (vmclear(>vc_control_pa)) {
> 

Did this result from the recent FPU rejiggery?

I think this has worked before in the past...

Re: VMs not booting (was: How to build with VMM_DEBUG)

[Mike Larkin]

On Sun, Jun 24, 2018 at 01:41:47AM -0500, Ax0n wrote:
> On Sat, Jun 23, 2018 at 3:54 PM, Ax0n  wrote:
> 
> >
> > FWIW, that patch didn't apply cleanly to a fresh pull of the tree from
> > GitHub. I know it's not OFFICIALLY -CURRENT for realsies but it's what I
> > have been using on this laptop for months. It sounds like it was probably
> > patched against -STABLE? I didn't read the entire thread on bugs@. I have
> > tried with 3 daily snapshots in a row and I'm having the same problem. I
> > haven't actually fired up vmm in a few weeks, so I'm not sure exactly when
> > it quit working. I'm re-building with VMM_DEBUG first.
> >
> > Mike, I'll send all relevant info (dmesg, vmd -dvvv, vm.conf) to bugs@
> > once I have it, unless this sounds like an ongoing thing you probably have
> > on your radar already. I'm not in a huge rush, so I can wait a bit if you
> > think you have something that'll make it into -CURRENT in a while.
> >
> 
> Following up and cc bugs@ I built the system with VMM_DEBUG enabled.
> 

This does not look like the output from a kernel with VMM_DEBUG enabled. You'll
be seeing all sorts of debug output to dmesg as the VM starts, runs, and
ultimately in your case aborts.

-ml

> >Synopsis:  vmm(4) VMs fail to start: ioctl failed: Invalid argument
> >Category:  amd64
> >Environment:
> System  : OpenBSD 6.3
> Details : OpenBSD 6.3-current (GENERIC.MP) #49: Sat Jun 23
> 09:32:05 MDT 2018
>  dera...@amd64.openbsd.org:
> /usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> VMs fail to boot.
> [axon@transient ~]$ doas vmd -dvvv
> startup
> /etc/vm.conf:4: switch "local" registered
> /etc/vm.conf:8: switch "internal" registered
> /etc/vm.conf:12: switch "wired" registered
> vm_register: registering vm 1
> /etc/vm.conf:28: vm "OBSD-Stable.vm" registered (disabled)
> vm_register: registering vm 2
> /etc/vm.conf:41: vm "OBSD-Stable-alt.vm" registered (disabled)
> vm_register: registering vm 3
> /etc/vm.conf:53: vm "OBSDSnap64.vm" registered (disabled)
> config_setconfig: setting config
> vm_priv_brconfig: interface bridge0 description switch1-local
> vm_priv_brconfig: interface bridge1 description switch2-internal
> vm_priv_brconfig: interface bridge0 description switch3-wired
> vmd_configure: not creating vm OBSD-Stable.vm (disabled)
> vmd_configure: not creating vm OBSD-Stable-alt.vm (disabled)
> vmd_configure: not creating vm OBSDSnap64.vm (disabled)
> config_getconfig: priv retrieving config
> config_getconfig: control retrieving config
> config_getconfig: vmm retrieving config
> vm_opentty: vm OBSDSnap64.vm tty /dev/ttyp3 uid 1000 gid 4 mode 620
> vm_register: registering vm 3
> vm_priv_ifconfig: interface tap0 description vm3-if0-OBSDSnap64.vm
> vm_priv_ifconfig: switch "local" interface bridge0 add tap0
> OBSDSnap64.vm: started vm 3 successfully, tty /dev/ttyp3
> loadfile_bios: loaded BIOS image
> run_vm: initializing hardware for vm OBSDSnap64.vm
> pic_set_elcr: setting level triggered mode for irq 3
> pic_set_elcr: setting level triggered mode for irq 5
> pic_set_elcr: setting level triggered mode for irq 6
> virtio_init: vm "OBSDSnap64.vm" vio0 lladdr fe:e1:ba:d0:eb:ac
> pic_set_elcr: setting level triggered mode for irq 7
> run_vm: starting vcpu threads for vm OBSDSnap64.vm
> vcpu_reset: resetting vcpu 0 for vm 2
> run_vm: waiting on events for VM OBSDSnap64.vm
> vcpu_run_loop: vm 2 / vcpu 0 run ioctl failed: Invalid argument
> vmm_sighdlr: handling signal 20
> vmm_sighdlr: attempting to terminate vm 3
> terminate_vm: terminating vmid 2
> vmm_sighdlr: calling vm_remove
> vm_remove: removing vm id 3 from running config
> vm_remove: calling vm_stop
> vm_stop: stopping vm 3
> vmd_dispatch_vmm: handling TERMINATE_EVENT for vm id 3 ret 22
> vmd_dispatch_vmm: about to stop vm id 3
> vm_stop: stopping vm 3
> vm_opentty: vm OBSDSnap64.vm tty /dev/ttyp4 uid 1000 gid 4 mode 620
> vm_register: registering vm 3
> vm_priv_ifconfig: interface tap0 description vm3-if0-OBSDSnap64.vm
> vm_priv_ifconfig: switch "local" interface bridge0 add tap0
> OBSDSnap64.vm: started vm 3 successfully, tty /dev/ttyp4
> loadfile_bios: loaded BIOS image
> run_vm: initializing hardware for vm OBSDSnap64.vm
> pic_set_elcr: setting level triggered mode for irq 3
> pic_set_elcr: setting level triggered mode for irq 5
> pic_set_elcr: setting level triggered mode for irq 6
> virtio_init: vm "OBSDSnap64.vm" vio0 lladdr fe:e1:ba:d0:eb:ac
> pic_set_elcr: setting level triggered mode for irq 7
> run_vm: starting vcpu threads for vm OBSDSnap64.vm
> vcpu_reset: resetting vcpu 0 for vm 3
> run_vm: waiting on events for VM OBSDSnap64.vm
> vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument
> vmm_sighdlr: handling signal 20
> vmm_sighdlr: attempting to terminate vm 3
> terminate_vm: terminating vmid 3
> vmm_sighdlr: calling vm_remove
> vm_remove: removing vm id 3 from running config
> 

Re: VMs not booting (was: How to build with VMM_DEBUG)

[Mike Larkin]

r ">lock"(rwlock) -> ">struct_mutex"(rwlock) first seen
> at:
> #0  witness_checkorder+0x4c0
> #1  _rw_enter_write+0x53
> #2  i915_gem_object_wait_rendering__nonblocking+0x1fa
> #3  i915_gem_fault+0x144
> #4  drm_fault+0x18a
> #5  uvm_fault+0x743
> #6  pageflttrap+0x14c
> #7  trap+0x2b6
> #8  recall_trap+0x8
> vm_impl_init_vmx: created vm_map @ 0x80d18000
> vm_resetcpu: resetting vm 1 vcpu 0 to power on defaults
> Guest EPTP = 0x1f95bd01e
> vmm_alloc_vpid: allocated VPID/ASID 1
> vmm_fpurestore: guest attempted to set invalid bits in xcr0
> vmm_free_vpid: freed VPID/ASID 1
> lock order reversal:
>  1st 0x80021668 acpilk (>sc_lck) @
> /mnt/src/sys/dev/acpi/acpi.c:2508
>  2nd 0x8015c278 mcrwl (>mode_config.mutex) @
> /mnt/src/sys/dev/pci/drm/drm_modeset_lock.c:76
> lock order ">mode_config.mutex"(rwlock) -> ">sc_lck"(rwlock) first
> seen at:
> #0  witness_checkorder+0x4c0
> #1  _rw_enter_write+0x53
> #2  acpivout_get_param+0xc8
> #3  inteldrm_backlight_get_brightness+0x39
> #4  get_properties+0x166
> #5  drm_mode_getconnector+0x33b
> #6  drm_do_ioctl+0x221
> #7  drmioctl+0xf9
> #8  VOP_IOCTL+0x5a
> #9  vn_ioctl+0x6b
> #10 sys_ioctl+0x477
> #11 syscall+0x32a
> #12 Xsyscall_untramp+0xe4
> video0 detached
> uvideo0 detached
> sd1 detached
> scsibus2 detached
> umass0 detached
> uhub2 detached
> uhub0 detached
> uhub3 detached
> uhub1 detached
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
> 2.00/1.00 addr 1
> uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
> 2.00/1.00 addr 1
> uhub2 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub"
> rev 2.00/0.00 addr 2
> uvideo0 at uhub2 port 1 configuration 1 interface 0 "SuYin 1.3M HD WebCam"
> rev 2.00/1.02 addr 3
> video0 at uvideo0
> umass0 at uhub2 port 2 configuration 1 interface 0 "Generic USB2.0-CRW" rev
> 2.00/38.82 addr 4
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> sd1 at scsibus2 targ 1 lun 0:  SCSI0 0/direct
> removable serial.0bda013851638820
> uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub"
> rev 2.00/0.00 addr 2
> vm_impl_init_vmx: created vm_map @ 0x80d3aa00
> vm_resetcpu: resetting vm 2 vcpu 0 to power on defaults
> Guest EPTP = 0x1f95bb01e
> vmm_alloc_vpid: allocated VPID/ASID 1
> vmm_fpurestore: guest attempted to set invalid bits in xcr0

That's the problem.

What's the guest VM you're trying to boot here? If it's OpenBSD, can
you give the build date and version?

Thanks.

-ml


> vmm_free_vpid: freed VPID/ASID 1
> 
> 
> 
> 
> 
> On Sun, Jun 24, 2018 at 2:33 PM, Mike Larkin  wrote:
> 
> > On Sun, Jun 24, 2018 at 01:41:47AM -0500, Ax0n wrote:
> > > On Sat, Jun 23, 2018 at 3:54 PM, Ax0n  wrote:
> > >
> > > >
> > > > FWIW, that patch didn't apply cleanly to a fresh pull of the tree from
> > > > GitHub. I know it's not OFFICIALLY -CURRENT for realsies but it's what
> > I
> > > > have been using on this laptop for months. It sounds like it was
> > probably
> > > > patched against -STABLE? I didn't read the entire thread on bugs@. I
> > have
> > > > tried with 3 daily snapshots in a row and I'm having the same problem.
> > I
> > > > haven't actually fired up vmm in a few weeks, so I'm not sure exactly
> > when
> > > > it quit working. I'm re-building with VMM_DEBUG first.
> > > >
> > > > Mike, I'll send all relevant info (dmesg, vmd -dvvv, vm.conf) to bugs@
> > > > once I have it, unless this sounds like an ongoing thing you probably
> > have
> > > > on your radar already. I'm not in a huge rush, so I can wait a bit if
> > you
> > > > think you have something that'll make it into -CURRENT in a while.
> > > >
> > >
> > > Following up and cc bugs@ I built the system with VMM_DEBUG enabled.
> > >
> >
> > This does not look like the output from a kernel with VMM_DEBUG enabled.
> > You'll
> > be seeing all sorts of debug output to dmesg as the VM starts, runs, and
> > ultimately in your case aborts.
> >
> > -ml
> >
> > > >Synopsis:  vmm(4) VMs fail to start: ioctl failed: Invalid argument
> > > >Category:  amd64
> > > >Environment:
> > > System  : OpenBSD 6.3
> > > Details : OpenBSD 6.3-current (GENERIC.MP) #49: Sat Jun 23
> > > 09:32:05 MDT 2018
> > 

Re: Thinkpad X1 Carbon 5th Gen: Flaky Suspend

[Mike Larkin]

On Thu, May 03, 2018 at 09:56:52AM +0100, Edd Barrett wrote:
> Hi,
> 
> On Fri, Jan 12, 2018 at 11:40:31AM +, Edd Barrett wrote:
> > For the month or so I've had it (usually updating my snapshot every week
> > or so) suspend has been a bit flaky. Often it does zzz and wake fine,
> > but occasionally (say 1 time out of 5), something goes wrong. Either:
> 
> Sorry to dig up an old thread. Just wanted to mention that my 5th
> generation X1 is still frequently failing to wake from suspend on newer
> snapshots.
> 
> Cheers
> 
> -- 
> Best Regards
> Edd Barrett
> 
> http://www.theunixzoo.co.uk
> 

You can help diagnose this yourself.

If the machine has a visual indicator of sleeping/waking (like a blinking led),
move the SST_WAKING acpi_indicator calls around in the resume path so you
can see where it's getting stuck.

If you get to the point that it's resuming devices and can't figure out which
device is broken, you can turn a "hang" into a "reset" by placing calls to
cpu_reset in various places, to let you know where it gets to. If it resets,
you know you got that far and can move the reset to later devices. that way
you can narrow down the area where it's hanging.

You can also use the vPro serial-over-lan and output messages there if your
machine supports that.

These sorts of techniques are what I used when diagnosing things when we were
first implementing suspend and hibernate, when the console is nonresponsive or
black or unavailable.

-ml

Re: acpidump: RSDT entry 3 is corrupt (ASUS P5Q Pro Turbo)

[Mike Larkin]

On Wed, May 02, 2018 at 04:03:50AM -0400, meg...@r53sound.com wrote:
> 
> >Synopsis: acpidump: RSDT entry 3 is corrupt on ASUS P5Q Pro Turbo
> >Category: system, or amd64?
> >Environment:
>  System : OpenBSD 6.3
>  Details : 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
> Architecture: OpenBSD.amd64
>  Machine : amd64
> >Description: Boot message indicates the ASUS P5Q Pro Turbo motherboard
> is supplying non-conforming ACPI table data.
> >How-To-Repeat: Install OpenBSD 6.3 on a system containing an ASUS P5Q Pro 
> >Turbo
> motherboard.
> >Fix: Out of my depth.
> SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached.
> SENDBUG: Feel free to delete or use the -D flag if they contain sensitive 
> information.
> dmesg:
> 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 = 8572567552 (8175MB)
> avail mem = 8305696768 (7920MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0740 (70 entries)
> bios0: vendor American Megatrends Inc. version "2102" date 02/23/2009

There is a new bios for this motherboard on the asus site. Can you apply that
update and see if this problem still exists? The table in question is supplied
by the BIOS.

-ml

> bios0: ASUSTeK Computer INC. P5Q-PRO
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR SSDT
> acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) EUSB(S4) USBE(S4) 
> P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) GBEC(S4) USB0(S4) USB1(S4) 
> USB2(S4) USB3(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)2 Quad CPU Q6600 @ 2.40GHz, 2880.41 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: 4MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 266MHz
> cpu0: mwait min=64, max=64, C-substates=0.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400.10 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu1: 4MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400.11 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu2: 4MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400.09 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu3: 4MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (P0P2)
> acpiprt2 at acpi0: bus -1 (P0P3)
> acpiprt3 at acpi0: bus 4 (P0P1)
> acpiprt4 at acpi0: bus -1 (P0P5)
> acpiprt5 at acpi0: bus -1 (P0P6)
> acpiprt6 at acpi0: bus -1 (P0P7)
> acpiprt7 at acpi0: bus -1 (P0P8)
> acpiprt8 at acpi0: bus 2 (P0P9)
> acpiprt9 at acpi0: bus 3 (P0P4)
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpicpu1 at acpi0: C1(@1 halt!), PSS
> acpicpu2 at acpi0: C1(@1 halt!), PSS
> acpicpu3 at acpi0: C1(@1 halt!), PSS
> aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM
> acpibtn0 at acpi0: PWRB
> cpu0: Enhanced SpeedStep 2880 MHz: speeds: 2403, 2136, 1870, 1603 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel G45 Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel G45 PCIE" rev 0x03: msi
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x67ef rev 0xcf
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> azalia0 at pci1 dev 0 function 1 vendor "ATI", unknown product 0xaae0 rev 
> 0x00: msi
> azalia0: no supported codecs
> uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: apic 4 int 16
> uhci1 at pci0 dev 26 function 1 

Re: LSI Logic MegaRAID SAS 9240-8i Panic

[Mike Larkin]

On Sun, Jan 07, 2018 at 04:57:22PM -0700, Shane Harbour wrote:
> Hello,
> I'm running into the following panic when trying to boot the OpenBSD 6.2
> release install disc (as well as the latest snapshot) with an LSI Logic
> MegaRAID SAS 9240-8i (mfi driver) card installed in the machine.  I take the
> card out and it boots just fine from the disc, but the following panic
> happens with the RAID card in:
> 
> ---
> boot>
> cannot open cd0a:/etc/random.see: No such file or directory
> booting cd0a:/6.2/amd64/bsd.rd: 3371132+1459200+3873512+0+598016
> [373741+82+427200+282103]=0x9e99c0
> entry point at 0x1000158
> panic: init_x86_64: can't find end of memory
> 
> The operating system has halted.
> Please press any key to reboot.
> ---
> 
> The system is in an Intel Core 2 Quad system with 8GB of RAM. The RAID is
> setup in two logical drives, one in RAID5 and the other in RAID1.
> 
> If you need any other information, just let me know.
> 
> Thanks,
> Shane
> 

sendbug from the working boot please

also please send output of "machine memory" from the boot> prompt, while
the card is plugged in.

-ml

Re: Kernel panics after some hours of use (likely related to modeset)

[Mike Larkin]

On Tue, Jan 09, 2018 at 12:44:04AM +0100, azarus wrote:
> To: bugs@openbsd.org
> Subject: Kernel panics after some hours of use (likely related to modeset)
> From: aza...@posteo.net
> Cc: aza...@posteo.net
> Reply-To: aza...@posteo.net
> 
> >Synopsis:The kernel panics reproducibly after a couple of hours of use 
> >(2-4 hours)
> >Category:system amd64 kernel
> >Environment:
>   System  : OpenBSD 6.2
>   Details : OpenBSD 6.2-current (GENERIC.MP) #333: Sun Jan  7 
> 09:13:00 MST 2018
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> In snapshots #320-#333 (every second snapshot or so tested) the kernel
> hangs reproducibly after some hours of use. During use I have a pdf
> viewer (mupdf), a browser (Firefox), tmux, an editor (nvim), a music
> player (mpd) and some shells open (zsh).
> 
> This issue happens often when I leave the computer for some minutes, so
> it might be something related to the screen turning off (modeset).
> 
> This might not be relevant, but I tried both with softdep enabled and
> disabled, to the same result.
> 
> The machine is a ThinkPad X230, with Coreboot. (But I doubt it's
> coreboot causing the issue, as the computer's not going to sleep)
> 
> I cannot provide a dmesg of the crashed system, as "boot dump" fails.
> 
> For the complete kernel error message, trace output, show registers
> ouput and ps output, please regard attached pictures.
> 
> >How-To-Repeat:
> 1. Use machine for a couple of hours
> 2. Leave machine for some time (5-15 minutes)
> 3. Kernel panics with "uvm_fault(0xfff81b4b158, 0x0, 0, 1) -> e"
> >Fix:
> unknown
> 

A few of us have been seeing this, so we know about the issue. There is
no fix at this time however. Thanks for reporting it though.

-ml

> dmesg:
> OpenBSD 6.2-current (GENERIC.MP) #333: Sun Jan  7 09:13:00 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8494600192 (8101MB)
> avail mem = 8230227968 (7848MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbff28020 (10 entries)
> bios0: vendor coreboot version "CBET4000 4.6-196-g0fb6568" date 05/22/2017
> bios0: LENOVO 2325YBN
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TCPA APIC DMAR HPET
> acpi0: wakeup devices HDEF(S4) EHC1(S4) EHC2(S4) XHC_(S4) SLPB(S3) LID_(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.53 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 2594107462 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.1.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.12 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.12 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.12 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 

Re: vmd: vcpu_run_loop: vm 2 / vcpu 0 run ioctl failed: Invalid argument

[Mike Larkin]

On Wed, Jan 17, 2018 at 01:28:51PM +0100, Martin Pieuchot wrote:
> I'm running an OpenBSD amd64 guest into an amd64 host.  Dmesgs
> attached.  The VM config is as follow:
> 
> vm "qemu" {
> memory 128M
> disk "/usr/hack/mpi/qemu/amd64/disk.img"
> local interface tap0 lladdr 70:5f:ca:21:8d:70
> disable
> owner mpi
> }
> 
> I run dhclient(8) and NAT the traffic using IP forwarding on my host.
> 
> vmd(8) exited multiple times with the following error:
>vmd[98149]: vcpu_run_loop: vm 2 / vcpu 0 run ioctl failed: Invalid argument
> 
> The last two times it happened it was at "reboot" time.  Once after upgrading
> the machine via bsd.rd.  After entering "Enter" when asked if I want to reboot
> vmd(8) crashed.  The second time it happened just after typing 'reboot' in a
>  ssh session.

3rd report of this in the last few weeks. Now it's happening here to me also.
I'll see if I can repro it.

-ml

> OpenBSD 6.2-current (GENERIC.MP) #369: Tue Jan 16 20:06:05 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8238301184 (7856MB)
> avail mem = 7981674496 (7611MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
> bios0: vendor LENOVO version "N14ET26W (1.04 )" date 01/23/2015
> bios0: LENOVO 20BS006BGE
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT 
> SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2295.08 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> acpihpet0: recalibrated TSC frequency 2394465630 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.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2294.69 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2294.69 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2294.69 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 3 (EXP1)
> acpiprt3 at acpi0: bus 4 (EXP2)
> acpiprt4 at acpi0: bus -1 (EXP3)
> acpiprt5 at acpi0: bus -1 (EXP6)
> acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
> C1(1000@1 mwait.1), PSS
>