acpi pci uhci reboot panic

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

acpi pci uhci reboot panic

Alexander Bluhm
Hi,

This commit breaks reboot on my performance test machines.

src/sys/dev/acpi/acpi.c
----------------------------
revision 1.373
date: 2019/08/28 22:39:09;  author: kettenis;  state: Exp;  lines: +2 -1;  commitid: QyX9yOMI2XcbppRc;
Use ACPI information to attach PCI busses like we do on arm64.  There are a
few additional quirks though, and attaching the PCI busses is delayed to
replicate the existing code more closely.  That may be changed in the
future.  Also tweak how we handle MSI support and respect to ACPI flag
that says we shouldn't attempt to use MSIs.

Some fallout is expected.

ok patrick@
----------------------------

uhci_run(ffff80000013d000,0) at uhci_run+0x40
uhci_activate(ffff80000013d000,6) at uhci_activate+0x117
config_activate_children(ffff8000000f1400,6) at config_activate_children+0x72
...
sys_reboot(ffff8000fffeeef0,ffff8000223e3fe0,ffff8000223e4040) at sys_reboot+0x
7e

../../../../../dev/usb/uhci.c:1370
    39c2:       bf 06 00 00 00          mov    $0x6,%edi
    39c7:       e8 00 00 00 00          callq  39cc <uhci_run+0x2c>
    39cc:       41 89 c4                mov    %eax,%r12d
machine/bus.h:481
    39cf:       0f ae f0                mfence %eax
../../../../../dev/usb/uhci.c:230
    39d2:       49 8b 86 c0 04 00 00    mov    0x4c0(%r14),%rax
    39d9:       49 8b be c8 04 00 00    mov    0x4c8(%r14),%rdi
*   39e0:       4c 8b 58 08             mov    0x8(%rax),%r11
    39e4:       45 31 ed                xor    %r13d,%r13d
    39e7:       31 f6                   xor    %esi,%esi
    39e9:       e8 00 00 00 00          callq  39ee <uhci_run+0x4e>
../../../../../dev/usb/uhci.c:1373
    39ee:       89 c1                   mov    %eax,%ecx
    39f0:       83 c9 01                or     $0x1,%ecx
    39f3:       83 e0 fe                and    $0xfffffffffffffffe,%eax

   226  __unused static __inline u_int16_t
   227  UREAD2(struct uhci_softc *sc, bus_size_t r)
   228  {
   229          UBARR(sc);
*  230          return bus_space_read_2(sc->iot, sc->ioh, r);
   231  }

  1370          s = splhardusb();
  1371          DPRINTF(("uhci_run: setting run=%d\n", run));
* 1372          cmd = UREAD2(sc, UHCI_CMD);
  1373          if (run)
  1374                  cmd |= UHCI_CMD_RS;
  1375          else
  1376                  cmd &= ~UHCI_CMD_RS;

#define bus_space_read_2(_t, _h, _o) ((_t)->read_2((_h), (_o)))

If I understand the assemlby correctly, sc->iot is NULL, so it
panics at sc->iot->read_2.

ddb{0}> show struct uhci_softc 0xffff80000013d000
struct uhci_softc at 0xffff80000013d000 (6568 bytes) {sc_bus = {bdev = {dv_clas
s = 0, dv_list = {tqe_next = (struct device *)0xffff80000013f000, tqe_prev = 0x
ffff8000000f6808}, dv_cfdata = (struct cfdata *)0xffffffff81f39d40, dv_unit = 0
x0, dv_xname = 207926552693, dv_parent = (struct device *)0xffff8000000f1400, d
v_flags = 0x1, dv_ref = 0x3}, methods = (struct usbd_bus_methods *)0x0, bpfif =
 (void *)0x0, bpf = (char *)0x0, pipe_size = 0x0, root_hub = (struct usbd_devic
e *)0x0, devices = 0, use_polling = 0x0, dying = 0x0, flags = 0x0, usbctl = (st
ruct device *)0x0, stats = {uds_requests = 0}, intr_context = 0x0, no_intrs = 0
x0, usbrev = 0x0, soft = (void *)0x0, dmatag = (struct bus_dma_tag *)0x0}, iot =
 (const x86_bus_space_ops *)0x0, ioh = 0x0, sc_size = 0x0, sc_pframes = (uhci_p
hysaddr_t *)0x0, sc_dma = {block = (struct usb_dma_block *)0x0, offs = 0x0}, sc
_vframes = 0, sc_lctl_start = (struct uhci_soft_qh *)0x0, sc_lctl_end = (struct
 uhci_soft_qh *)0x0, sc_hctl_start = (struct uhci_soft_qh *)0x0, sc_hctl_end = (
struct uhci_soft_qh *)0x0, sc_bulk_start = (struct uhci_soft_qh *)0x0, sc_bulk_
end = (struct uhci_soft_qh *)0x0, sc_last_qh = (struct uhci_soft_qh *)0x0, sc_l
oops = 0x0, sc_freetds = (struct uhci_soft_td *)0x0, sc_freeqhs = (struct uhci_
soft_qh *)0x0, sc_conf = 0x0, sc_saved_sof = 0x0, sc_saved_frnum = 0x0, sc_soft
wake = 0x0, sc_isreset = 0x0, sc_suspend = 0x0, sc_intrhead = {lh_first = (stru
ct uhci_xfer *)0x0}, sc_intrxfer = (struct usbd_xfer *)0x0, sc_root_intr = {to_
list = {next = (struct circq *)0x0, prev = (struct circq *)0x0}, to_func = 0x0,
 to_arg = (void *)0x0, to_time = 0x0, to_flags = 0x0}, sc_vendor = 0, sc_id_ven
dor = 0x0}

Details below from a previos crash with a snapshot kernel.

OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep  1 22:36:53 MDT 2019
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6416760832 (6119MB)
avail mem = 6209593344 (5921MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
bios0: Supermicro X8DTH-i/6/iF/6F
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG SPMI OEMB HPET DMAR SSDT EINJ BERT ERST HEST
acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.81 MHz, 06-1a-05
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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
TSC skew=4
cpu1: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.44 MHz, 06-1a-05
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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
tsc_timecounter_init: TSC skew=4 observed drift=0
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
TSC skew=4
cpu2: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.44 MHz, 06-1a-05
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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
tsc_timecounter_init: TSC skew=4 observed drift=0
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
TSC skew=-14
cpu3: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.44 MHz, 06-1a-05
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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
tsc_timecounter_init: TSC skew=-14 observed drift=0
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
ioapic1 at mainbus0: apid 3 pa 0xfec8a000, version 20, 24 pins, remapped
ioapic2 at mainbus0: apid 5 pa 0xfec9a000, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (NPE1)
acpiprt2 at acpi0: bus -1 (NPE2)
acpiprt3 at acpi0: bus 2 (NPE3)
acpiprt4 at acpi0: bus -1 (NPE4)
acpiprt5 at acpi0: bus 3 (NPE5)
acpiprt6 at acpi0: bus -1 (NPE6)
acpiprt7 at acpi0: bus 4 (NPE7)
acpiprt8 at acpi0: bus -1 (NPE8)
acpiprt9 at acpi0: bus 5 (NPE9)
acpiprt10 at acpi0: bus -1 (NPEA)
acpiprt11 at acpi0: bus 6 (P0P1)
acpiprt12 at acpi0: bus -1 (P0P4)
acpiprt13 at acpi0: bus -1 (P0P5)
acpiprt14 at acpi0: bus -1 (P0P6)
acpiprt15 at acpi0: bus -1 (P0P7)
acpiprt16 at acpi0: bus -1 (P0P8)
acpiprt17 at acpi0: bus -1 (P0P9)
acpiprt18 at acpi0: bus 128 (BR50)
acpiprt19 at acpi0: bus 130 (NPE1)
acpiprt20 at acpi0: bus -1 (NPE2)
acpiprt21 at acpi0: bus 131 (NPE3)
acpiprt22 at acpi0: bus -1 (NPE4)
acpiprt23 at acpi0: bus 132 (NPE5)
acpiprt24 at acpi0: bus -1 (NPE6)
acpiprt25 at acpi0: bus 133 (NPE7)
acpiprt26 at acpi0: bus -1 (NPE8)
acpiprt27 at acpi0: bus 134 (NPE9)
acpiprt28 at acpi0: bus -1 (NPEA)
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
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
acpipci1 at acpi0 BR50
acpibtn0 at acpi0: PWRB
pci0 at acpipci0 bus 0
0:1:0: bridge io address conflict 0xb000/0x1000
0:5:0: bridge io address conflict 0xc000/0x1000
0:9:0: bridge io address conflict 0xd000/0x1000
0:19:0: mem address conflict 0xfec8a000/0x1000
0:26:0: io address conflict 0x9f80/0x20
0:26:1: io address conflict 0x9f40/0x20
0:29:0: io address conflict 0x9f20/0x20
0:29:1: io address conflict 0x9f00/0x20
0:29:2: io address conflict 0x9ec0/0x20
0:31:2: io address conflict 0x9ff0/0x8
0:31:2: io address conflict 0x9fac/0x4
0:31:2: io address conflict 0x9fe0/0x8
0:31:2: io address conflict 0x9fa8/0x4
0:31:2: io address conflict 0x9ea0/0x20
pchb0 at pci0 dev 0 function 0 "Intel 5520 Host" rev 0x22
ppb0 at pci0 dev 1 function 0 "Intel X58 PCIE" rev 0x22: msi
pci1 at ppb0 bus 1
1:0:0: io address conflict 0xbf80/0x20
1:0:1: io address conflict 0xbf40/0x20
em0 at pci1 dev 0 function 0 "Intel 82576" rev 0x01: msi, address 00:25:90:04:bf:78
em1 at pci1 dev 0 function 1 "Intel 82576" rev 0x01: msi, address 00:25:90:04:bf:79
ppb1 at pci0 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 5 function 0 "Intel X58 PCIE" rev 0x22: msi
pci3 at ppb2 bus 3
ix0 at pci3 dev 0 function 0 "Intel 82598AF" rev 0x01: msi, address 00:1b:21:0d:db:8f
ppb3 at pci0 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi
pci4 at ppb3 bus 4
ppb4 at pci0 dev 9 function 0 "Intel X58 PCIE" rev 0x22: msi
pci5 at ppb4 bus 5
mpii0 at pci5 dev 0 function 0 "Symbios Logic SAS2008" rev 0x02: msi
mpii0: LSI SAS2008, firmware 2.0.50.0 IR, MPI 2.0
scsibus1 at mpii0: 128 targets
sd0 at scsibus1 targ 0 lun 0: <LSI, Logical Volume, 3000> SCSI6 0/direct fixed naa.600508e000000000b125ed4b59bd5204
sd0: 139236MB, 512 bytes/sector, 285155329 sectors
"Intel X58 IOxAPIC" rev 0x22 at pci0 dev 19 function 0 not configured
"Intel X58 Misc" rev 0x22 at pci0 dev 20 function 0 not configured
"Intel X58 GPIO" rev 0x22 at pci0 dev 20 function 1 not configured
"Intel X58 RAS" rev 0x22 at pci0 dev 20 function 2 not configured
"Intel X58 Throttle" rev 0x22 at pci0 dev 20 function 3 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 0 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 1 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 2 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 3 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 4 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 5 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 6 not configured
"Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 7 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
ehci0 at pci0 dev 26 function 7 "Intel 82801JI USB" rev 0x00: apic 1 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
uhci2 at pci0 dev 29 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
uhci3 at pci0 dev 29 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
uhci4 at pci0 dev 29 function 2 "Intel 82801JI USB" rev 0x00: can't map i/o space
ehci1 at pci0 dev 29 function 7 "Intel 82801JI USB" rev 0x00: apic 1 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb5 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x90
pci6 at ppb5 bus 6
vga1 at pci6 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801JIR LPC" rev 0x00
ahci0 at pci0 dev 31 function 2 "Intel 82801JI AHCI" rev 0x00: msi, AHCI 1.2
ahci0: port 0: 1.5Gb/s
scsibus2 at ahci0: 32 targets
cd0 at scsibus2 targ 0 lun 0: <TEAC, DV-W28S-R, 1.0B> ATAPI 5/cdrom removable
ichiic0 at pci0 dev 31 function 3 "Intel 82801JI SMBus" rev 0x00: apic 1 int 18
iic0 at ichiic0
iic0: addr 0x2e 00=40 words 00=4040 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
nvt0 at iic0 addr 0x2f: W83795ADG
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: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG-P rev 0x73
lm1 at wbsio0 port 0xa10/8: W83627DHG
pci7 at acpipci1 bus 128
128:19:0: mem address conflict 0xfec9a000/0x1000
ppb6 at pci7 dev 0 function 0 vendor "Intel", unknown product 0x3420 rev 0x13
pci8 at ppb6 bus 129
ppb7 at pci7 dev 1 function 0 "Intel X58 PCIE" rev 0x22: msi
pci9 at ppb7 bus 130
ppb8 at pci7 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi
pci10 at ppb8 bus 131
ppb9 at pci7 dev 5 function 0 "Intel X58 PCIE" rev 0x22: msi
pci11 at ppb9 bus 132
ppb10 at pci7 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi
pci12 at ppb10 bus 133
ppb11 at pci7 dev 9 function 0 "Intel X58 PCIE" rev 0x22: msi
pci13 at ppb11 bus 134
ix1 at pci13 dev 0 function 0 "Intel 82598AT" rev 0x01: msi, address 00:1b:21:a3:93:98
"Intel X58 IOxAPIC" rev 0x22 at pci7 dev 19 function 0 not configured
"Intel X58 Misc" rev 0x22 at pci7 dev 20 function 0 not configured
"Intel X58 GPIO" rev 0x22 at pci7 dev 20 function 1 not configured
"Intel X58 RAS" rev 0x22 at pci7 dev 20 function 2 not configured
"Intel X58 Throttle" rev 0x22 at pci7 dev 20 function 3 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 0 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 1 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 2 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 3 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 4 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 5 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 6 not configured
"Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 7 not configured
ipmi at mainbus0 not configured
cpu0: using IvyBridge MDS workaround
cpu0: Enhanced SpeedStep 2933 MHz: speeds: 2933, 2800, 2667, 2533, 2400, 2267, 2133, 2000, 1867, 1733, 1600 MHz
vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (fda5f2318850053d.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (fda5f2318850053d.a): file system is clean; not checking
/dev/sd0k (fda5f2318850053d.k): file system is clean; not checking
/dev/sd0d (fda5f2318850053d.d): file system is clean; not checking
/dev/sd0f (fda5f2318850053d.f): file system is clean; not checking
/dev/sd0g (fda5f2318850053d.g): file system is clean; not checking
/dev/sd0h (fda5f2318850053d.h): file system is clean; not checking
/dev/sd0j (fda5f2318850053d.j): file system is clean; not checking
/dev/sd0i (fda5f2318850053d.i): file system is clean; not checking
/dev/sd0e (fda5f2318850053d.e): file system is clean; not checking
pf enabled
ddb.console: 0 -> 1
kern.allowkmem: 0 -> 0
kern.pool_debug: 1 -> 0
kern.splassert: 1 -> 0
sysctl: kern.witnesswatch: value is not available
starting network
reordering libraries: done.
openssl: generating isakmpd/iked RSA keys... done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
acpidump: XSDT entry 4 is corrupt
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
running rc.firsttime
Path to firmware: http://firmware.openbsd.org/firmware/snapshots/
Installing: intel-firmware vmm-firmware
http://firmware.openbsd.org/firmware/snapshots/: ftp: connect: No route to host
http://firmware.openbsd.org/firmware/snapshots/: empty
Can't find intel-firmware
Can't find vmm-firmware
starting local daemons: cron.
Mon Sep  2 12:30:01 CEST 2019

OpenBSD/amd64 (ot14.obsd-lab.genua.de) (tty00)

login: [-- MARK -- Mon Sep  2 13:00:00 2019]
syncing disks... done
uvm_fault(0xfffffd818db91228, 0x8, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      uhci_run+0x40:  movq    0x8(%rax),%r11
ddb{0}> trace
uhci_run(ffff80000013d000,0) at uhci_run+0x40
uhci_activate(ffff80000013d000,6) at uhci_activate+0x117
config_activate_children(ffff8000000f1400,6) at config_activate_children+0x72
pciactivate(ffff8000000f1400,6) at pciactivate+0x51
config_activate_children(ffff8000000f1000,6) at config_activate_children+0x72
config_activate_children(ffff800000021400,6) at config_activate_children+0xb9
config_activate_children(ffff800000023180,6) at config_activate_children+0xb9
config_activate_children(ffff800000023100,6) at config_activate_children+0xb9
config_suspend_all(6) at config_suspend_all+0x1b2
boot(0) at boot+0xd1
reboot(0) at reboot+0x5c
sys_reboot(ffff8000fffeeef0,ffff8000223e3fe0,ffff8000223e4040) at sys_reboot+0x
7e
syscall(ffff8000223e40b0) at syscall+0x389
Xsyscall(6,37,0,37,c3f2403337,0) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7ffffee390, count: -14
ddb{0}> show register
rdi                                0
rsi                                0
rbp               0xffff8000223e3c80
rbx                              0x4
rdx                                0
rcx               0xffffffff81f30ff0    cpu_info_full_primary+0x1ff0
rax                                0
r8                0xffff8000223e3b9c
r9                                 0
r10               0xadcca5dc8d8ea175
r11               0xfe64858bf7f2fdf9
r12                              0xd
r13                              0x6
r14               0xffff80000013d000
r15                                0
rip               0xffffffff81566a70    uhci_run+0x40
cs                               0x8
rflags                       0x10246    __ALIGN_SIZE+0xf246
rsp               0xffff8000223e3c40
ss                              0x10
uhci_run+0x40:  movq    0x8(%rax),%r11
ddb{0}> ps
   PID     TID   PPID    UID  S       FLAGS  WAIT          COMMAND
*41579  292451      1      0  7         0x2                reboot
 48594  367439      0      0  3     0x14280  nfsidl        nfsio
 98911  111041      0      0  3     0x14280  nfsidl        nfsio
 21929   46950      0      0  3     0x14280  nfsidl        nfsio
 46340  171979      0      0  3     0x14280  nfsidl        nfsio
 64036  225653      0      0  3     0x14200  pgzero        zerothread
  8150  465642      0      0  3     0x14200  aiodoned      aiodoned
 20843  489625      0      0  3     0x14200  syncer        update
 69075  432771      0      0  3     0x14200  cleaner       cleaner
 48762   41231      0      0  3     0x14200  reaper        reaper
 40698  384396      0      0  3     0x14200  pgdaemon      pagedaemon
 91633   35225      0      0  3     0x14200  bored         crynlk
 85808   11651      0      0  3     0x14200  bored         crypto
 94849  332033      0      0  3     0x14200  usbtsk        usbtask
 58443  265792      0      0  3     0x14200  usbatsk       usbatsk
  5021  203767      0      0  3  0x40014200  acpi0         acpi0
 27071  378796      0      0  7  0x40014200                idle3
 68857  311056      0      0  7  0x40014200                idle2
 87418  476954      0      0  7  0x40014200                idle1
 36220  171141      0      0  3     0x14200  bored         sensors
  7158  445387      0      0  3     0x14200  bored         softnet
 14465  459243      0      0  3     0x14200  bored         systqmp
 95832  101088      0      0  3     0x14200  bored         systq
 49304  198702      0      0  3  0x40014200  bored         softclock
 76474  491583      0      0  3  0x40014200                idle0
 37882   88557      0      0  3     0x14200  bored         smr
     1  415088      0      0  3        0x82  wait          init
     0       0     -1      0  3     0x10200  scheduler     swapper
ddb{0}>

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Mark Kettenis
> Date: Mon, 2 Sep 2019 16:49:56 +0200
> From: Alexander Bluhm <[hidden email]>
>
> Hi,
>
> This commit breaks reboot on my performance test machines.

I'll need acpidump output for that machine.

> src/sys/dev/acpi/acpi.c
> ----------------------------
> revision 1.373
> date: 2019/08/28 22:39:09;  author: kettenis;  state: Exp;  lines: +2 -1;  commitid: QyX9yOMI2XcbppRc;
> Use ACPI information to attach PCI busses like we do on arm64.  There are a
> few additional quirks though, and attaching the PCI busses is delayed to
> replicate the existing code more closely.  That may be changed in the
> future.  Also tweak how we handle MSI support and respect to ACPI flag
> that says we shouldn't attempt to use MSIs.
>
> Some fallout is expected.
>
> ok patrick@
> ----------------------------
>
> uhci_run(ffff80000013d000,0) at uhci_run+0x40
> uhci_activate(ffff80000013d000,6) at uhci_activate+0x117
> config_activate_children(ffff8000000f1400,6) at config_activate_children+0x72
> ...
> sys_reboot(ffff8000fffeeef0,ffff8000223e3fe0,ffff8000223e4040) at sys_reboot+0x
> 7e
>
> ../../../../../dev/usb/uhci.c:1370
>     39c2:       bf 06 00 00 00          mov    $0x6,%edi
>     39c7:       e8 00 00 00 00          callq  39cc <uhci_run+0x2c>
>     39cc:       41 89 c4                mov    %eax,%r12d
> machine/bus.h:481
>     39cf:       0f ae f0                mfence %eax
> ../../../../../dev/usb/uhci.c:230
>     39d2:       49 8b 86 c0 04 00 00    mov    0x4c0(%r14),%rax
>     39d9:       49 8b be c8 04 00 00    mov    0x4c8(%r14),%rdi
> *   39e0:       4c 8b 58 08             mov    0x8(%rax),%r11
>     39e4:       45 31 ed                xor    %r13d,%r13d
>     39e7:       31 f6                   xor    %esi,%esi
>     39e9:       e8 00 00 00 00          callq  39ee <uhci_run+0x4e>
> ../../../../../dev/usb/uhci.c:1373
>     39ee:       89 c1                   mov    %eax,%ecx
>     39f0:       83 c9 01                or     $0x1,%ecx
>     39f3:       83 e0 fe                and    $0xfffffffffffffffe,%eax
>
>    226  __unused static __inline u_int16_t
>    227  UREAD2(struct uhci_softc *sc, bus_size_t r)
>    228  {
>    229          UBARR(sc);
> *  230          return bus_space_read_2(sc->iot, sc->ioh, r);
>    231  }
>
>   1370          s = splhardusb();
>   1371          DPRINTF(("uhci_run: setting run=%d\n", run));
> * 1372          cmd = UREAD2(sc, UHCI_CMD);
>   1373          if (run)
>   1374                  cmd |= UHCI_CMD_RS;
>   1375          else
>   1376                  cmd &= ~UHCI_CMD_RS;
>
> #define bus_space_read_2(_t, _h, _o) ((_t)->read_2((_h), (_o)))
>
> If I understand the assemlby correctly, sc->iot is NULL, so it
> panics at sc->iot->read_2.
>
> ddb{0}> show struct uhci_softc 0xffff80000013d000
> struct uhci_softc at 0xffff80000013d000 (6568 bytes) {sc_bus = {bdev = {dv_clas
> s = 0, dv_list = {tqe_next = (struct device *)0xffff80000013f000, tqe_prev = 0x
> ffff8000000f6808}, dv_cfdata = (struct cfdata *)0xffffffff81f39d40, dv_unit = 0
> x0, dv_xname = 207926552693, dv_parent = (struct device *)0xffff8000000f1400, d
> v_flags = 0x1, dv_ref = 0x3}, methods = (struct usbd_bus_methods *)0x0, bpfif =
>  (void *)0x0, bpf = (char *)0x0, pipe_size = 0x0, root_hub = (struct usbd_devic
> e *)0x0, devices = 0, use_polling = 0x0, dying = 0x0, flags = 0x0, usbctl = (st
> ruct device *)0x0, stats = {uds_requests = 0}, intr_context = 0x0, no_intrs = 0
> x0, usbrev = 0x0, soft = (void *)0x0, dmatag = (struct bus_dma_tag *)0x0}, iot =
>  (const x86_bus_space_ops *)0x0, ioh = 0x0, sc_size = 0x0, sc_pframes = (uhci_p
> hysaddr_t *)0x0, sc_dma = {block = (struct usb_dma_block *)0x0, offs = 0x0}, sc
> _vframes = 0, sc_lctl_start = (struct uhci_soft_qh *)0x0, sc_lctl_end = (struct
>  uhci_soft_qh *)0x0, sc_hctl_start = (struct uhci_soft_qh *)0x0, sc_hctl_end = (
> struct uhci_soft_qh *)0x0, sc_bulk_start = (struct uhci_soft_qh *)0x0, sc_bulk_
> end = (struct uhci_soft_qh *)0x0, sc_last_qh = (struct uhci_soft_qh *)0x0, sc_l
> oops = 0x0, sc_freetds = (struct uhci_soft_td *)0x0, sc_freeqhs = (struct uhci_
> soft_qh *)0x0, sc_conf = 0x0, sc_saved_sof = 0x0, sc_saved_frnum = 0x0, sc_soft
> wake = 0x0, sc_isreset = 0x0, sc_suspend = 0x0, sc_intrhead = {lh_first = (stru
> ct uhci_xfer *)0x0}, sc_intrxfer = (struct usbd_xfer *)0x0, sc_root_intr = {to_
> list = {next = (struct circq *)0x0, prev = (struct circq *)0x0}, to_func = 0x0,
>  to_arg = (void *)0x0, to_time = 0x0, to_flags = 0x0}, sc_vendor = 0, sc_id_ven
> dor = 0x0}
>
> Details below from a previos crash with a snapshot kernel.
>
> OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep  1 22:36:53 MDT 2019
>     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 6416760832 (6119MB)
> avail mem = 6209593344 (5921MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
> bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
> bios0: Supermicro X8DTH-i/6/iF/6F
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC MCFG SPMI OEMB HPET DMAR SSDT EINJ BERT ERST HEST
> acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.81 MHz, 06-1a-05
> 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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> tsc_timecounter_init: TSC skew=0 observed drift=0
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 133MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> TSC skew=4
> cpu1: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.44 MHz, 06-1a-05
> 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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> tsc_timecounter_init: TSC skew=4 observed drift=0
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> TSC skew=4
> cpu2: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.44 MHz, 06-1a-05
> 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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> tsc_timecounter_init: TSC skew=4 observed drift=0
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> TSC skew=-14
> cpu3: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz, 2933.44 MHz, 06-1a-05
> 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,DCA,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> tsc_timecounter_init: TSC skew=-14 observed drift=0
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins, remapped
> ioapic1 at mainbus0: apid 3 pa 0xfec8a000, version 20, 24 pins, remapped
> ioapic2 at mainbus0: apid 5 pa 0xfec9a000, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe0000000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (NPE1)
> acpiprt2 at acpi0: bus -1 (NPE2)
> acpiprt3 at acpi0: bus 2 (NPE3)
> acpiprt4 at acpi0: bus -1 (NPE4)
> acpiprt5 at acpi0: bus 3 (NPE5)
> acpiprt6 at acpi0: bus -1 (NPE6)
> acpiprt7 at acpi0: bus 4 (NPE7)
> acpiprt8 at acpi0: bus -1 (NPE8)
> acpiprt9 at acpi0: bus 5 (NPE9)
> acpiprt10 at acpi0: bus -1 (NPEA)
> acpiprt11 at acpi0: bus 6 (P0P1)
> acpiprt12 at acpi0: bus -1 (P0P4)
> acpiprt13 at acpi0: bus -1 (P0P5)
> acpiprt14 at acpi0: bus -1 (P0P6)
> acpiprt15 at acpi0: bus -1 (P0P7)
> acpiprt16 at acpi0: bus -1 (P0P8)
> acpiprt17 at acpi0: bus -1 (P0P9)
> acpiprt18 at acpi0: bus 128 (BR50)
> acpiprt19 at acpi0: bus 130 (NPE1)
> acpiprt20 at acpi0: bus -1 (NPE2)
> acpiprt21 at acpi0: bus 131 (NPE3)
> acpiprt22 at acpi0: bus -1 (NPE4)
> acpiprt23 at acpi0: bus 132 (NPE5)
> acpiprt24 at acpi0: bus -1 (NPE6)
> acpiprt25 at acpi0: bus 133 (NPE7)
> acpiprt26 at acpi0: bus -1 (NPE8)
> acpiprt27 at acpi0: bus 134 (NPE9)
> acpiprt28 at acpi0: bus -1 (NPEA)
> 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
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> acpipci1 at acpi0 BR50
> acpibtn0 at acpi0: PWRB
> pci0 at acpipci0 bus 0
> 0:1:0: bridge io address conflict 0xb000/0x1000
> 0:5:0: bridge io address conflict 0xc000/0x1000
> 0:9:0: bridge io address conflict 0xd000/0x1000
> 0:19:0: mem address conflict 0xfec8a000/0x1000
> 0:26:0: io address conflict 0x9f80/0x20
> 0:26:1: io address conflict 0x9f40/0x20
> 0:29:0: io address conflict 0x9f20/0x20
> 0:29:1: io address conflict 0x9f00/0x20
> 0:29:2: io address conflict 0x9ec0/0x20
> 0:31:2: io address conflict 0x9ff0/0x8
> 0:31:2: io address conflict 0x9fac/0x4
> 0:31:2: io address conflict 0x9fe0/0x8
> 0:31:2: io address conflict 0x9fa8/0x4
> 0:31:2: io address conflict 0x9ea0/0x20
> pchb0 at pci0 dev 0 function 0 "Intel 5520 Host" rev 0x22
> ppb0 at pci0 dev 1 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci1 at ppb0 bus 1
> 1:0:0: io address conflict 0xbf80/0x20
> 1:0:1: io address conflict 0xbf40/0x20
> em0 at pci1 dev 0 function 0 "Intel 82576" rev 0x01: msi, address 00:25:90:04:bf:78
> em1 at pci1 dev 0 function 1 "Intel 82576" rev 0x01: msi, address 00:25:90:04:bf:79
> ppb1 at pci0 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 5 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci3 at ppb2 bus 3
> ix0 at pci3 dev 0 function 0 "Intel 82598AF" rev 0x01: msi, address 00:1b:21:0d:db:8f
> ppb3 at pci0 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci4 at ppb3 bus 4
> ppb4 at pci0 dev 9 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci5 at ppb4 bus 5
> mpii0 at pci5 dev 0 function 0 "Symbios Logic SAS2008" rev 0x02: msi
> mpii0: LSI SAS2008, firmware 2.0.50.0 IR, MPI 2.0
> scsibus1 at mpii0: 128 targets
> sd0 at scsibus1 targ 0 lun 0: <LSI, Logical Volume, 3000> SCSI6 0/direct fixed naa.600508e000000000b125ed4b59bd5204
> sd0: 139236MB, 512 bytes/sector, 285155329 sectors
> "Intel X58 IOxAPIC" rev 0x22 at pci0 dev 19 function 0 not configured
> "Intel X58 Misc" rev 0x22 at pci0 dev 20 function 0 not configured
> "Intel X58 GPIO" rev 0x22 at pci0 dev 20 function 1 not configured
> "Intel X58 RAS" rev 0x22 at pci0 dev 20 function 2 not configured
> "Intel X58 Throttle" rev 0x22 at pci0 dev 20 function 3 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 0 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 1 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 2 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 3 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 4 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 5 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 6 not configured
> "Intel X58 QuickData" rev 0x22 at pci0 dev 22 function 7 not configured
> uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
> uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
> ehci0 at pci0 dev 26 function 7 "Intel 82801JI USB" rev 0x00: apic 1 int 18
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> uhci2 at pci0 dev 29 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
> uhci3 at pci0 dev 29 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
> uhci4 at pci0 dev 29 function 2 "Intel 82801JI USB" rev 0x00: can't map i/o space
> ehci1 at pci0 dev 29 function 7 "Intel 82801JI USB" rev 0x00: apic 1 int 23
> usb1 at ehci1: USB revision 2.0
> uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb5 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x90
> pci6 at ppb5 bus 6
> vga1 at pci6 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pcib0 at pci0 dev 31 function 0 "Intel 82801JIR LPC" rev 0x00
> ahci0 at pci0 dev 31 function 2 "Intel 82801JI AHCI" rev 0x00: msi, AHCI 1.2
> ahci0: port 0: 1.5Gb/s
> scsibus2 at ahci0: 32 targets
> cd0 at scsibus2 targ 0 lun 0: <TEAC, DV-W28S-R, 1.0B> ATAPI 5/cdrom removable
> ichiic0 at pci0 dev 31 function 3 "Intel 82801JI SMBus" rev 0x00: apic 1 int 18
> iic0 at ichiic0
> iic0: addr 0x2e 00=40 words 00=4040 01=0000 02=0000 03=0000 04=0000 05=0000 06=0000 07=0000
> nvt0 at iic0 addr 0x2f: W83795ADG
> 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: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> wbsio0 at isa0 port 0x2e/2: W83627DHG-P rev 0x73
> lm1 at wbsio0 port 0xa10/8: W83627DHG
> pci7 at acpipci1 bus 128
> 128:19:0: mem address conflict 0xfec9a000/0x1000
> ppb6 at pci7 dev 0 function 0 vendor "Intel", unknown product 0x3420 rev 0x13
> pci8 at ppb6 bus 129
> ppb7 at pci7 dev 1 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci9 at ppb7 bus 130
> ppb8 at pci7 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci10 at ppb8 bus 131
> ppb9 at pci7 dev 5 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci11 at ppb9 bus 132
> ppb10 at pci7 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci12 at ppb10 bus 133
> ppb11 at pci7 dev 9 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci13 at ppb11 bus 134
> ix1 at pci13 dev 0 function 0 "Intel 82598AT" rev 0x01: msi, address 00:1b:21:a3:93:98
> "Intel X58 IOxAPIC" rev 0x22 at pci7 dev 19 function 0 not configured
> "Intel X58 Misc" rev 0x22 at pci7 dev 20 function 0 not configured
> "Intel X58 GPIO" rev 0x22 at pci7 dev 20 function 1 not configured
> "Intel X58 RAS" rev 0x22 at pci7 dev 20 function 2 not configured
> "Intel X58 Throttle" rev 0x22 at pci7 dev 20 function 3 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 0 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 1 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 2 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 3 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 4 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 5 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 6 not configured
> "Intel X58 QuickData" rev 0x22 at pci7 dev 22 function 7 not configured
> ipmi at mainbus0 not configured
> cpu0: using IvyBridge MDS workaround
> cpu0: Enhanced SpeedStep 2933 MHz: speeds: 2933, 2800, 2667, 2533, 2400, 2267, 2133, 2000, 1867, 1733, 1600 MHz
> vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on sd0a (fda5f2318850053d.a) swap on sd0b dump on sd0b
> Automatic boot in progress: starting file system checks.
> /dev/sd0a (fda5f2318850053d.a): file system is clean; not checking
> /dev/sd0k (fda5f2318850053d.k): file system is clean; not checking
> /dev/sd0d (fda5f2318850053d.d): file system is clean; not checking
> /dev/sd0f (fda5f2318850053d.f): file system is clean; not checking
> /dev/sd0g (fda5f2318850053d.g): file system is clean; not checking
> /dev/sd0h (fda5f2318850053d.h): file system is clean; not checking
> /dev/sd0j (fda5f2318850053d.j): file system is clean; not checking
> /dev/sd0i (fda5f2318850053d.i): file system is clean; not checking
> /dev/sd0e (fda5f2318850053d.e): file system is clean; not checking
> pf enabled
> ddb.console: 0 -> 1
> kern.allowkmem: 0 -> 0
> kern.pool_debug: 1 -> 0
> kern.splassert: 1 -> 0
> sysctl: kern.witnesswatch: value is not available
> starting network
> reordering libraries: done.
> openssl: generating isakmpd/iked RSA keys... done.
> starting early daemons: syslogd pflogd ntpd.
> starting RPC daemons:.
> savecore: no core dump
> acpidump: XSDT entry 4 is corrupt
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> starting network daemons: sshd smtpd sndiod.
> running rc.firsttime
> Path to firmware: http://firmware.openbsd.org/firmware/snapshots/
> Installing: intel-firmware vmm-firmware
> http://firmware.openbsd.org/firmware/snapshots/: ftp: connect: No route to host
> http://firmware.openbsd.org/firmware/snapshots/: empty
> Can't find intel-firmware
> Can't find vmm-firmware
> starting local daemons: cron.
> Mon Sep  2 12:30:01 CEST 2019
>
> OpenBSD/amd64 (ot14.obsd-lab.genua.de) (tty00)
>
> login: [-- MARK -- Mon Sep  2 13:00:00 2019]
> syncing disks... done
> uvm_fault(0xfffffd818db91228, 0x8, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at      uhci_run+0x40:  movq    0x8(%rax),%r11
> ddb{0}> trace
> uhci_run(ffff80000013d000,0) at uhci_run+0x40
> uhci_activate(ffff80000013d000,6) at uhci_activate+0x117
> config_activate_children(ffff8000000f1400,6) at config_activate_children+0x72
> pciactivate(ffff8000000f1400,6) at pciactivate+0x51
> config_activate_children(ffff8000000f1000,6) at config_activate_children+0x72
> config_activate_children(ffff800000021400,6) at config_activate_children+0xb9
> config_activate_children(ffff800000023180,6) at config_activate_children+0xb9
> config_activate_children(ffff800000023100,6) at config_activate_children+0xb9
> config_suspend_all(6) at config_suspend_all+0x1b2
> boot(0) at boot+0xd1
> reboot(0) at reboot+0x5c
> sys_reboot(ffff8000fffeeef0,ffff8000223e3fe0,ffff8000223e4040) at sys_reboot+0x
> 7e
> syscall(ffff8000223e40b0) at syscall+0x389
> Xsyscall(6,37,0,37,c3f2403337,0) at Xsyscall+0x128
> end of kernel
> end trace frame: 0x7f7ffffee390, count: -14
> ddb{0}> show register
> rdi                                0
> rsi                                0
> rbp               0xffff8000223e3c80
> rbx                              0x4
> rdx                                0
> rcx               0xffffffff81f30ff0    cpu_info_full_primary+0x1ff0
> rax                                0
> r8                0xffff8000223e3b9c
> r9                                 0
> r10               0xadcca5dc8d8ea175
> r11               0xfe64858bf7f2fdf9
> r12                              0xd
> r13                              0x6
> r14               0xffff80000013d000
> r15                                0
> rip               0xffffffff81566a70    uhci_run+0x40
> cs                               0x8
> rflags                       0x10246    __ALIGN_SIZE+0xf246
> rsp               0xffff8000223e3c40
> ss                              0x10
> uhci_run+0x40:  movq    0x8(%rax),%r11
> ddb{0}> ps
>    PID     TID   PPID    UID  S       FLAGS  WAIT          COMMAND
> *41579  292451      1      0  7         0x2                reboot
>  48594  367439      0      0  3     0x14280  nfsidl        nfsio
>  98911  111041      0      0  3     0x14280  nfsidl        nfsio
>  21929   46950      0      0  3     0x14280  nfsidl        nfsio
>  46340  171979      0      0  3     0x14280  nfsidl        nfsio
>  64036  225653      0      0  3     0x14200  pgzero        zerothread
>   8150  465642      0      0  3     0x14200  aiodoned      aiodoned
>  20843  489625      0      0  3     0x14200  syncer        update
>  69075  432771      0      0  3     0x14200  cleaner       cleaner
>  48762   41231      0      0  3     0x14200  reaper        reaper
>  40698  384396      0      0  3     0x14200  pgdaemon      pagedaemon
>  91633   35225      0      0  3     0x14200  bored         crynlk
>  85808   11651      0      0  3     0x14200  bored         crypto
>  94849  332033      0      0  3     0x14200  usbtsk        usbtask
>  58443  265792      0      0  3     0x14200  usbatsk       usbatsk
>   5021  203767      0      0  3  0x40014200  acpi0         acpi0
>  27071  378796      0      0  7  0x40014200                idle3
>  68857  311056      0      0  7  0x40014200                idle2
>  87418  476954      0      0  7  0x40014200                idle1
>  36220  171141      0      0  3     0x14200  bored         sensors
>   7158  445387      0      0  3     0x14200  bored         softnet
>  14465  459243      0      0  3     0x14200  bored         systqmp
>  95832  101088      0      0  3     0x14200  bored         systq
>  49304  198702      0      0  3  0x40014200  bored         softclock
>  76474  491583      0      0  3  0x40014200                idle0
>  37882   88557      0      0  3     0x14200  bored         smr
>      1  415088      0      0  3        0x82  wait          init
>      0       0     -1      0  3     0x10200  scheduler     swapper
> ddb{0}>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Alexander Bluhm
On Mon, Sep 02, 2019 at 05:40:39PM +0200, Mark Kettenis wrote:
> > This commit breaks reboot on my performance test machines.
>
> I'll need acpidump output for that machine.

Note that I get this error:
acpidump: XSDT entry 4 is corrupt

acpidump and pcidump attached.

bluhm

APIC.3 (412 bytes) Download Attachment
DSDT.2 (39K) Download Attachment
FACP.1 (338 bytes) Download Attachment
MCFG.4 (84 bytes) Download Attachment
SPMI.5 (92 bytes) Download Attachment
XSDT.0 (182 bytes) Download Attachment
headers (1K) Download Attachment
pcidump (52K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Mark Kettenis
Can you run with this patch and send me a new dmesg?  Also can you
send me pcidump output from before my diff?  Alternatively you could
disable acpipci(4) and send me pcidump output from that.

Index: arch/amd64/pci/acpipci.c
===================================================================
RCS file: /cvs/src/sys/arch/amd64/pci/acpipci.c,v
retrieving revision 1.2
diff -u -p -r1.2 acpipci.c
--- arch/amd64/pci/acpipci.c 28 Aug 2019 22:39:09 -0000 1.2
+++ arch/amd64/pci/acpipci.c 2 Sep 2019 22:54:27 -0000
@@ -143,6 +143,10 @@ acpipci_attach(struct device *parent, st
 
  printf("\n");
 
+ extent_print(sc->sc_busex);
+ extent_print(sc->sc_ioex);
+ extent_print(sc->sc_memex);
+
  acpi_haspci = 1;
 
  sc->sc_iot = aaa->aaa_iot;

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Alexander Bluhm
On Tue, Sep 03, 2019 at 12:57:38AM +0200, Mark Kettenis wrote:
> Can you run with this patch and send me a new dmesg?  Also can you
> send me pcidump output from before my diff?  Alternatively you could
> disable acpipci(4) and send me pcidump output from that.

Old and new dmesg and pcidump without and with your diffs attached.

bluhm

dmesg-old (10K) Download Attachment
dmesg-new (11K) Download Attachment
pcidump-old (50K) Download Attachment
pcidump-new (50K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Mark Kettenis
In reply to this post by Alexander Bluhm
> Date: Mon, 2 Sep 2019 16:49:56 +0200
> From: Alexander Bluhm <[hidden email]>

I'm still looking into this issue.   However:

> OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep  1 22:36:53 MDT 2019
>     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 6416760832 (6119MB)
> avail mem = 6209593344 (5921MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
> bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
> bios0: Supermicro X8DTH-i/6/iF/6F

This happens to be one of the few systems that is blacklistted by
Linux.  Still thinking about a better approach.

I'd also like to point out that the following messages:

> uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
> uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space

mean that uhci(4) didn't fully attach but that the driver's activate
function doesn't properly check that the registers are accessable.

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Theo de Raadt-2
Mark Kettenis <[hidden email]> wrote:

> > Date: Mon, 2 Sep 2019 16:49:56 +0200
> > From: Alexander Bluhm <[hidden email]>
>
> I'm still looking into this issue.   However:
>
> > OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep  1 22:36:53 MDT 2019
> >     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 6416760832 (6119MB)
> > avail mem = 6209593344 (5921MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
> > bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
> > bios0: Supermicro X8DTH-i/6/iF/6F
>
> This happens to be one of the few systems that is blacklistted by
> Linux.  Still thinking about a better approach.
>
> I'd also like to point out that the following messages:
>
> > uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
> > uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
>
> mean that uhci(4) didn't fully attach but that the driver's activate
> function doesn't properly check that the registers are accessable.

Speaking broadly, These "don't fully attach" drivers are a disturbing problem.

It is a weakness in Torek's configuration subsystem that the probe/match
routine cannot early-execute a complex detection and then pass the result
to the attach routine.  Pretty obvious how it came about, in sparc / OFW
systems these kinds of "there but not there" conditions are impossible.

In that world, a match function only looks at the parent-bus, not at
child-device characteristics.

Not being able to pass a partial result from match -> attach, means
trying to setup-and-some-checking would require duplication of code in
both match & attach functions.  Since people don't want to duplicate
code, they don't do so.  They they allow the match to complete, and
silently to finish the job correctly in attach.  But having suceeded to
match, the device is now in the device-tree and later code will call some
of the methods....

Another possible approach would be that attach can return a failure,
rather than void.  If an attach function returns failure, remove it from
the device tree, so that the methods are unreachable.  Like an undo of
the match.  This would be a huge diff adjusting return conditions of all
attach functions.

If the mapping cannot be solved, maybe the activate function can skip
all work if sc->sc.sc_size is 0.



Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Mark Kettenis
> From: "Theo de Raadt" <[hidden email]>
> Date: Wed, 04 Sep 2019 07:43:18 -0600
>
> Mark Kettenis <[hidden email]> wrote:
>
> > > Date: Mon, 2 Sep 2019 16:49:56 +0200
> > > From: Alexander Bluhm <[hidden email]>
> >
> > I'm still looking into this issue.   However:
> >
> > > OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep  1 22:36:53 MDT 2019
> > >     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > real mem = 6416760832 (6119MB)
> > > avail mem = 6209593344 (5921MB)
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
> > > bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
> > > bios0: Supermicro X8DTH-i/6/iF/6F
> >
> > This happens to be one of the few systems that is blacklistted by
> > Linux.  Still thinking about a better approach.
> >
> > I'd also like to point out that the following messages:
> >
> > > uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
> > > uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
> >
> > mean that uhci(4) didn't fully attach but that the driver's activate
> > function doesn't properly check that the registers are accessable.
>
> Speaking broadly, These "don't fully attach" drivers are a disturbing problem.
>
> It is a weakness in Torek's configuration subsystem that the probe/match
> routine cannot early-execute a complex detection and then pass the result
> to the attach routine.  Pretty obvious how it came about, in sparc / OFW
> systems these kinds of "there but not there" conditions are impossible.
>
> In that world, a match function only looks at the parent-bus, not at
> child-device characteristics.
>
> Not being able to pass a partial result from match -> attach, means
> trying to setup-and-some-checking would require duplication of code in
> both match & attach functions.  Since people don't want to duplicate
> code, they don't do so.  They they allow the match to complete, and
> silently to finish the job correctly in attach.  But having suceeded to
> match, the device is now in the device-tree and later code will call some
> of the methods....
>
> Another possible approach would be that attach can return a failure,
> rather than void.  If an attach function returns failure, remove it from
> the device tree, so that the methods are unreachable.  Like an undo of
> the match.  This would be a huge diff adjusting return conditions of all
> attach functions.

For complex drivers, it is impossible to check everything up front.

> If the mapping cannot be solved, maybe the activate function can skip
> all work if sc->sc.sc_size is 0.

So this is, IMHO, the only viable approach.  I just wanted to trick
somebody else into doing the work ;).

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Theo de Raadt-2
Mark Kettenis <[hidden email]> wrote:

> > From: "Theo de Raadt" <[hidden email]>
> > Date: Wed, 04 Sep 2019 07:43:18 -0600
> >
> > Mark Kettenis <[hidden email]> wrote:
> >
> > > > Date: Mon, 2 Sep 2019 16:49:56 +0200
> > > > From: Alexander Bluhm <[hidden email]>
> > >
> > > I'm still looking into this issue.   However:
> > >
> > > > OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep  1 22:36:53 MDT 2019
> > > >     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > real mem = 6416760832 (6119MB)
> > > > avail mem = 6209593344 (5921MB)
> > > > mpath0 at root
> > > > scsibus0 at mpath0: 256 targets
> > > > mainbus0 at root
> > > > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
> > > > bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
> > > > bios0: Supermicro X8DTH-i/6/iF/6F
> > >
> > > This happens to be one of the few systems that is blacklistted by
> > > Linux.  Still thinking about a better approach.
> > >
> > > I'd also like to point out that the following messages:
> > >
> > > > uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map i/o space
> > > > uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map i/o space
> > >
> > > mean that uhci(4) didn't fully attach but that the driver's activate
> > > function doesn't properly check that the registers are accessable.
> >
> > Speaking broadly, These "don't fully attach" drivers are a disturbing problem.
> >
> > It is a weakness in Torek's configuration subsystem that the probe/match
> > routine cannot early-execute a complex detection and then pass the result
> > to the attach routine.  Pretty obvious how it came about, in sparc / OFW
> > systems these kinds of "there but not there" conditions are impossible.
> >
> > In that world, a match function only looks at the parent-bus, not at
> > child-device characteristics.
> >
> > Not being able to pass a partial result from match -> attach, means
> > trying to setup-and-some-checking would require duplication of code in
> > both match & attach functions.  Since people don't want to duplicate
> > code, they don't do so.  They they allow the match to complete, and
> > silently to finish the job correctly in attach.  But having suceeded to
> > match, the device is now in the device-tree and later code will call some
> > of the methods....
> >
> > Another possible approach would be that attach can return a failure,
> > rather than void.  If an attach function returns failure, remove it from
> > the device tree, so that the methods are unreachable.  Like an undo of
> > the match.  This would be a huge diff adjusting return conditions of all
> > attach functions.
>
> For complex drivers, it is impossible to check everything up front.

By "up front" I assume you mean in probe.  The 2nd approach isn't up
front, it is in attach.  Removing devices which failed to to complete
attach would still be a valid approach.

 If the mapping cannot be solved, maybe the activate function can skip
> > all work if sc->sc.sc_size is 0.
>
> So this is, IMHO, the only viable approach.  I just wanted to trick
> somebody else into doing the work ;).

I think it is a valid shortcut.

But I think changing the return signature of attach to "int" would be
quite helpful.

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Luke Small
In reply to this post by Alexander Bluhm
I see the potential with making the automatic updates find only the
encrypted partition, but I have the same problem on the same motherboard as
the thread-owner. How do I run -current with an encrypted partition when
the encrypted partition is invisible to even bioctl into it when I disable
ACPI, which is what I have to do to the newest bsd.rd?

It is bricked for now
--
-Luke
Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Mark Kettenis
> From: Luke Small <[hidden email]>
> Date: Wed, 4 Sep 2019 14:00:14 -0500
>
> I see the potential with making the automatic updates find only the
> encrypted partition, but I have the same problem on the same motherboard as
> the thread-owner. How do I run -current with an encrypted partition when
> the encrypted partition is invisible to even bioctl into it when I disable
> ACPI, which is what I have to do to the newest bsd.rd?
>
> It is bricked for now

You can disable acpipci(4); that should restore the previous behavuiour.

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Luke Small
I have an encrypted partition. Ihave to take a miniroot65.fs or something
to manually download bsd.rd from cdn.openbsd.org snapshots then reboot and
“boot bsd.rd -c” and disable acpipci and it freezes when it tries to fsck
partition ‘a’

On Wed, Sep 4, 2019 at 3:26 PM Luke Small <[hidden email]> wrote:

> It did that before. Then I managed to get a ramdisk to work and it got
> fucked
>
> On Wed, Sep 4, 2019 at 3:20 PM Luke Small <[hidden email]> wrote:
>
>> It freezes on “Checking root filesystem (fsck -fp /dev/sd1a)
>>
>> On Wed, Sep 4, 2019 at 2:59 PM Mark Kettenis <[hidden email]>
>> wrote:
>>
>>> > From: Luke Small <[hidden email]>
>>> > Date: Wed, 4 Sep 2019 14:00:14 -0500
>>> >
>>> > I see the potential with making the automatic updates find only the
>>> > encrypted partition, but I have the same problem on the same
>>> motherboard as
>>> > the thread-owner. How do I run -current with an encrypted partition
>>> when
>>> > the encrypted partition is invisible to even bioctl into it when I
>>> disable
>>> > ACPI, which is what I have to do to the newest bsd.rd?
>>> >
>>> > It is bricked for now
>>>
>>> You can disable acpipci(4); that should restore the previous behavuiour.
>>>
>> --
>> -Luke
>>
> --
> -Luke
>
--
-Luke
Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Alexander Bluhm
In reply to this post by Mark Kettenis
On Wed, Sep 04, 2019 at 03:54:25PM +0200, Mark Kettenis wrote:
> > If the mapping cannot be solved, maybe the activate function can skip
> > all work if sc->sc.sc_size is 0.
>
> So this is, IMHO, the only viable approach.  I just wanted to trick
> somebody else into doing the work ;).

ehci does that.

----------------------------
revision 1.31
date: 2019/05/02 20:28:46;  author: kettenis;  state: Exp;  lines: +8 -4;  commitid: UueNy7svryPLHN1X;
Avoid running the activate function for a partially attached ehci(4) driver.
The Realtek DASH ehci(4) doesn't have a properly set SBRN register which
prevents us from fully attaching the device.  This would result in a panic
during suspend because the activate function will access register that
aren't mapped.

ok deraadt@
----------------------------

If I do the same for uhci, it solves my problem.

ok?

bluhm

Index: dev/pci/uhci_pci.c
===================================================================
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/uhci_pci.c,v
retrieving revision 1.33
diff -u -p -r1.33 uhci_pci.c
--- dev/pci/uhci_pci.c 16 May 2014 18:17:03 -0000 1.33
+++ dev/pci/uhci_pci.c 5 Sep 2019 16:15:44 -0000
@@ -86,6 +86,9 @@ uhci_pci_activate(struct device *self, i
 {
  struct uhci_pci_softc *sc = (struct uhci_pci_softc *)self;

+ if (sc->sc.sc_size == 0)
+ return 0;
+
  /* On resume, set legacy support attribute and enable intrs */
  switch (act) {
  case DVACT_RESUME:
@@ -190,6 +193,7 @@ uhci_pci_attach(struct device *parent, s

 unmap_ret:
  bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
+ sc->sc.sc_size = 0;
  splx(s);
 }

@@ -218,6 +222,7 @@ uhci_pci_attach_deferred(struct device *
 unmap_ret:
  bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
  pci_intr_disestablish(sc->sc_pc, sc->sc_ih);
+ sc->sc.sc_size = 0;
  splx(s);
 }

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Theo de Raadt-2
Good enough.

Alexander Bluhm <[hidden email]> wrote:

> On Wed, Sep 04, 2019 at 03:54:25PM +0200, Mark Kettenis wrote:
> > > If the mapping cannot be solved, maybe the activate function can skip
> > > all work if sc->sc.sc_size is 0.
> >
> > So this is, IMHO, the only viable approach.  I just wanted to trick
> > somebody else into doing the work ;).
>
> ehci does that.
>
> ----------------------------
> revision 1.31
> date: 2019/05/02 20:28:46;  author: kettenis;  state: Exp;  lines: +8 -4;  commitid: UueNy7svryPLHN1X;
> Avoid running the activate function for a partially attached ehci(4) driver.
> The Realtek DASH ehci(4) doesn't have a properly set SBRN register which
> prevents us from fully attaching the device.  This would result in a panic
> during suspend because the activate function will access register that
> aren't mapped.
>
> ok deraadt@
> ----------------------------
>
> If I do the same for uhci, it solves my problem.
>
> ok?
>
> bluhm
>
> Index: dev/pci/uhci_pci.c
> ===================================================================
> RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/uhci_pci.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 uhci_pci.c
> --- dev/pci/uhci_pci.c 16 May 2014 18:17:03 -0000 1.33
> +++ dev/pci/uhci_pci.c 5 Sep 2019 16:15:44 -0000
> @@ -86,6 +86,9 @@ uhci_pci_activate(struct device *self, i
>  {
>   struct uhci_pci_softc *sc = (struct uhci_pci_softc *)self;
>
> + if (sc->sc.sc_size == 0)
> + return 0;
> +
>   /* On resume, set legacy support attribute and enable intrs */
>   switch (act) {
>   case DVACT_RESUME:
> @@ -190,6 +193,7 @@ uhci_pci_attach(struct device *parent, s
>
>  unmap_ret:
>   bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
> + sc->sc.sc_size = 0;
>   splx(s);
>  }
>
> @@ -218,6 +222,7 @@ uhci_pci_attach_deferred(struct device *
>  unmap_ret:
>   bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
>   pci_intr_disestablish(sc->sc_pc, sc->sc_ih);
> + sc->sc.sc_size = 0;
>   splx(s);
>  }
>

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Mark Kettenis
In reply to this post by Alexander Bluhm
> Date: Thu, 5 Sep 2019 18:23:37 +0200
> From: Alexander Bluhm <[hidden email]>
>
> On Wed, Sep 04, 2019 at 03:54:25PM +0200, Mark Kettenis wrote:
> > > If the mapping cannot be solved, maybe the activate function can skip
> > > all work if sc->sc.sc_size is 0.
> >
> > So this is, IMHO, the only viable approach.  I just wanted to trick
> > somebody else into doing the work ;).
>
> ehci does that.
>
> ----------------------------
> revision 1.31
> date: 2019/05/02 20:28:46;  author: kettenis;  state: Exp;  lines: +8 -4;  commitid: UueNy7svryPLHN1X;
> Avoid running the activate function for a partially attached ehci(4) driver.
> The Realtek DASH ehci(4) doesn't have a properly set SBRN register which
> prevents us from fully attaching the device.  This would result in a panic
> during suspend because the activate function will access register that
> aren't mapped.
>
> ok deraadt@
> ----------------------------
>
> If I do the same for uhci, it solves my problem.

Well, not really since USB 1.1 devices won't work...

> ok?

ok kettenis@

> Index: dev/pci/uhci_pci.c
> ===================================================================
> RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/uhci_pci.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 uhci_pci.c
> --- dev/pci/uhci_pci.c 16 May 2014 18:17:03 -0000 1.33
> +++ dev/pci/uhci_pci.c 5 Sep 2019 16:15:44 -0000
> @@ -86,6 +86,9 @@ uhci_pci_activate(struct device *self, i
>  {
>   struct uhci_pci_softc *sc = (struct uhci_pci_softc *)self;
>
> + if (sc->sc.sc_size == 0)
> + return 0;
> +
>   /* On resume, set legacy support attribute and enable intrs */
>   switch (act) {
>   case DVACT_RESUME:
> @@ -190,6 +193,7 @@ uhci_pci_attach(struct device *parent, s
>
>  unmap_ret:
>   bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
> + sc->sc.sc_size = 0;
>   splx(s);
>  }
>
> @@ -218,6 +222,7 @@ uhci_pci_attach_deferred(struct device *
>  unmap_ret:
>   bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
>   pci_intr_disestablish(sc->sc_pc, sc->sc_ih);
> + sc->sc.sc_size = 0;
>   splx(s);
>  }
>
>

Reply | Threaded
Open this post in threaded view
|

Re: acpi pci uhci reboot panic

Luke Small
In reply to this post by Luke Small
I just loaded the bsd.rd and it still doesn't work.

On Wed, Sep 4, 2019 at 4:44 PM Luke Small <[hidden email]> wrote:

> I have an encrypted partition. Ihave to take a miniroot65.fs or something
> to manually download bsd.rd from cdn.openbsd.org snapshots then reboot
> and “boot bsd.rd -c” and disable acpipci and it freezes when it tries to
> fsck partition ‘a’
>
> On Wed, Sep 4, 2019 at 3:26 PM Luke Small <[hidden email]> wrote:
>
>> It did that before. Then I managed to get a ramdisk to work and it got
>> fucked
>>
>> On Wed, Sep 4, 2019 at 3:20 PM Luke Small <[hidden email]> wrote:
>>
>>> It freezes on “Checking root filesystem (fsck -fp /dev/sd1a)
>>>
>>> On Wed, Sep 4, 2019 at 2:59 PM Mark Kettenis <[hidden email]>
>>> wrote:
>>>
>>>> > From: Luke Small <[hidden email]>
>>>> > Date: Wed, 4 Sep 2019 14:00:14 -0500
>>>> >
>>>> > I see the potential with making the automatic updates find only the
>>>> > encrypted partition, but I have the same problem on the same
>>>> motherboard as
>>>> > the thread-owner. How do I run -current with an encrypted partition
>>>> when
>>>> > the encrypted partition is invisible to even bioctl into it when I
>>>> disable
>>>> > ACPI, which is what I have to do to the newest bsd.rd?
>>>> >
>>>> > It is bricked for now
>>>>
>>>> You can disable acpipci(4); that should restore the previous behavuiour.
>>>>
>>> --
>>> -Luke
>>>
>> --
>> -Luke
>>
> --
> -Luke
>
--
-Luke