NetBSD Problem Report #56050
From www@netbsd.org Wed Mar 10 08:09:43 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 50D271A9217
for <gnats-bugs@gnats.NetBSD.org>; Wed, 10 Mar 2021 08:09:43 +0000 (UTC)
Message-Id: <20210310080941.DC6C51A923A@mollari.NetBSD.org>
Date: Wed, 10 Mar 2021 08:09:41 +0000 (UTC)
From: nia@pkgsrc.org
Reply-To: nia@pkgsrc.org
To: gnats-bugs@NetBSD.org
Subject: xhci suspend/resume is unimplemented
X-Send-Pr-Version: www-1.0
>Number: 56050
>Category: kern
>Synopsis: xhci suspend/resume is unimplemented
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Mar 10 08:10:00 +0000 2021
>Closed-Date: Fri Jun 04 16:28:19 +0000 2021
>Last-Modified: Mon Jun 21 17:15:01 +0000 2021
>Originator: nia
>Release: NetBSD 9.99.80
>Organization:
>Environment:
NetBSD r 9.99.80 NetBSD 9.99.80 (GENERIC) #0: Fri Mar 5 20:30:56 UTC 2021 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
>How-To-Repeat:
Attempt to suspend laptop with USB3 (in this case, lenovo x250). USB ports no longer function after successful resume.
>Fix:
xhci_resume and xhci_suspend should probably not be stub functions.
There is an XXX in xhci.c where UHF_PORT_SUSPEND should be handled.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 23 May 2021 12:09:42 +0000
State-Changed-Why:
draft xhci suspend/resume
https://mail-index.netbsd.org/source-changes/2021/05/23/msg129705.html
State-Changed-From-To: feedback->closed
State-Changed-By: nia@NetBSD.org
State-Changed-When: Sun, 23 May 2021 17:01:00 +0000
State-Changed-Why:
When my machine does not lock up due to current having other resume
regressions, this works great. Thanks!
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
nia@netbsd.org, Taylor R Campbell <riastradh@netbsd.org>
Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
Date: Wed, 26 May 2021 12:09:45 +0300
The latest xhci.c rev 1.140 changes are causing panic in my system if
any xhci device (or at least with my USB stick and/or external SSD) is
connected. The previous commit still works (suspend/resume draft).
Interestingly enough and probably irrelevant, the kernel does not
crash with serial console boot on 115200 speed (still fails on default
9600 speed though).
dmesg below:
entropy: entering seed from bootloader with 256 bits of entropy
mainbus0 (root)
ACPI: RSDP 0x00000000000F05A0 000024 (v02 ALASKA)
ACPI: XSDT 0x00000000DBF750A0 0000C4 (v01 ALASKA A M I 01072009 AMI
00010013)
ACPI: FACP 0x00000000DBF7A810 000114 (v06 ALASKA A M I 01072009 AMI
00010013)
ACPI: DSDT 0x00000000DBF75200 005610 (v02 ALASKA A M I 01072009
INTL 20120913)
ACPI: FACS 0x00000000DC011E00 000040
ACPI: APIC 0x00000000DBF7A928 00015E (v03 ALASKA A M I 01072009 AMI
00010013)
ACPI: FPDT 0x00000000DBF7AA88 000044 (v01 ALASKA A M I 01072009 AMI
00010013)
ACPI: FIDT 0x00000000DBF7AAD0 00009C (v01 ALASKA A M I 01072009 AMI
00010013)
ACPI: SSDT 0x00000000DBF7AB70 0000C8 (v02 ALASKA CPUSSDT 01072009 AMI
01072009)
ACPI: SSDT 0x00000000DBF7AC38 008C98 (v02 AMD AMD ALIB 00000002
MSFT 04000000)
ACPI: SSDT 0x00000000DBF838D0 0036B9 (v01 AMD AMD AOD 00000001
INTL 20120913)
ACPI: MCFG 0x00000000DBF86F90 00003C (v01 ALASKA A M I 01072009
MSFT 00010013)
ACPI: BHMB 0x00000000DBF86FD0 000474 (v01 ALASKA A M I 00000001 AMI
00000001)
ACPI: HPET 0x00000000DBF87448 000038 (v01 ALASKA A M I 01072009 AMI
00000005)
ACPI: UEFI 0x00000000DBF87480 000042 (v01 ALASKA A M I 00000002
01000013)
ACPI: TPM2 0x00000000DBF874C8 000038 (v04 ALASKA A M I 00000001 AMI
00000000)
ACPI: IVRS 0x00000000DBF87500 0000D0 (v02 AMD AMD IVRS 00000001 AMD
00000000)
ACPI: PCCT 0x00000000DBF875D0 00006E (v01 AMD AMD PCCT 00000001 AMD
00000000)
ACPI: SSDT 0x00000000DBF87640 002F29 (v01 AMD AMD CPU 00000001 AMD
00000001)
ACPI: CRAT 0x00000000DBF8A570 000B58 (v01 AMD AMD CRAT 00000001 AMD
00000001)
ACPI: CDIT 0x00000000DBF8B0C8 000029 (v01 AMD AMD CDIT 00000001 AMD
00000001)
ACPI: SSDT 0x00000000DBF8B0F8 001D4A (v01 AMD AmdTable 00000001
INTL 20120913)
ACPI: SSDT 0x00000000DBF8CE48 0000BF (v01 AMD AMD PT 00001000
INTL 20120913)
ACPI: WSMT 0x00000000DBF8CF08 000028 (v01 ALASKA A M I 01072009 AMI
00010013)
ACPI: 7 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 13
ioapic1 at mainbus0 apid 14
cpu0 at mainbus0 apid 0
cpu0: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu0: node 0, package 0, core 0, smt 0
cpu1 at mainbus0 apid 2
cpu1: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu1: node 0, package 0, core 1, smt 0
cpu2 at mainbus0 apid 4
cpu2: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu2: node 0, package 0, core 2, smt 0
cpu3 at mainbus0 apid 8
cpu3: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu3: node 0, package 0, core 4, smt 0
cpu4 at mainbus0 apid 10
cpu4: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu4: node 0, package 0, core 5, smt 0
cpu5 at mainbus0 apid 12
cpu5: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu5: node 0, package 0, core 6, smt 0
cpu6 at mainbus0 apid 1
cpu6: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu6: node 0, package 0, core 0, smt 1
cpu7 at mainbus0 apid 3
cpu7: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu7: node 0, package 0, core 1, smt 1
cpu8 at mainbus0 apid 5
cpu8: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu8: node 0, package 0, core 2, smt 1
cpu9 at mainbus0 apid 9
cpu9: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu9: node 0, package 0, core 4, smt 1
cpu10 at mainbus0 apid 11
cpu10: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu10: node 0, package 0, core 5, smt 1
cpu11 at mainbus0 apid 13
cpu11: AMD Ryzen 5 3600 6-Core Processor , id 0x870f10
cpu11: node 0, package 0, core 6, smt 1
acpi0 at mainbus0: Intel ACPICA 20210331
acpi0: invalid PCI address for D020
acpi0: fixed power button present
hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400)
AMDN (PNP0C01) at acpi0 not configured
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
spkr0 at pcppi1: PC Speaker
wsbell at spkr0 not configured
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
pckbc1 at acpi0 (PS2K, PNP0303-0) (kbd port): io 0x60,0x64 irq 1
UAR1 (PNP0501) at acpi0 not configured
acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button
GPIO (AMDI0030) at acpi0 not configured
TPM (MSFT0101) at acpi0 not configured
PTIO (AMDIF030) at acpi0 not configured
acpitz0 at acpi0 (THRM)
acpiwmi0 at acpi0 (AOD, PNP0C14-AOD): ACPI WMI Interface
acpiwmibus at acpiwmi0 not configured
ACPI: Enabled 1 GPEs in block 00 to 1F
attimer1: attached to pcppi1
pckbd0 at pckbc1 (kbd slot)
pckbc1: using irq 1 for kbd slot
wskbd0 at pckbd0 mux 1
pci0 at mainbus0 bus 0: configuration mode 1
amdsmn0 at pci0 dev 0 function 0: AMD System Management Network
amdzentemp0 at amdsmn0: AMD CPU Temperature Sensors (Family17h)
AMD Family17h/7xh IOMMU (IOMMU system) at pci0 dev 0 function 2 not configured
pchb0 at pci0 dev 1 function 0: AMD product 1482 (rev. 0x00)
ppb0 at pci0 dev 1 function 1: AMD product 1483 (rev. 0x00)
ppb0: PCI Express capability version 2 <Root Port of PCI-E Root
Complex> x8 @ 8.0GT/s
ppb0: link is x4 @ 8.0GT/s
pci1 at ppb0 bus 1
xhci0 at pci1 dev 0 function 0: AMD product 43b9 (rev. 0x02)
xhci0: interrupting at msi0 vec 0
usb0 at xhci0: USB revision 3.1
usb1 at xhci0: USB revision 2.0
ahcisata0 at pci1 dev 0 function 1: AMD product 43b5 (rev. 0x02)
ahcisata0: AHCI revision 1.31, 8 ports, 32 slots, CAP
0xef36ff27<SXS,PSC,SSC,PMD,SPM,SAM,ISS=0x3=Gen3,SCLO,SAL,SALP,SSS,SSNTF,SNCQ,S64A>
ahcisata0: interrupting at msi1 vec 0
atabus0 at ahcisata0 channel 0
atabus1 at ahcisata0 channel 1
atabus2 at ahcisata0 channel 2
atabus3 at ahcisata0 channel 3
atabus4 at ahcisata0 channel 4
atabus5 at ahcisata0 channel 5
atabus6 at ahcisata0 channel 6
atabus7 at ahcisata0 channel 7
ppb1 at pci1 dev 0 function 2: AMD product 43b0 (rev. 0x02)
ppb1: PCI Express capability version 2 <Upstream Port of PCI-E Switch>
pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb2: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x1 @ 5.0GT/s
pci3 at ppb2 bus 3
ppb3 at pci2 dev 1 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb3: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x1 @ 5.0GT/s
ppb3: link is x1 @ 2.5GT/s
pci4 at ppb3 bus 4
ppb4 at pci4 dev 0 function 0: ASMedia ASM1083/1085 PCIe-PCI Bridge (rev. 0x03)
pci5 at ppb4 bus 5
ppb5 at pci2 dev 2 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb5: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x1 @ 5.0GT/s
pci6 at ppb5 bus 6
ppb6 at pci2 dev 3 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb6: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x1 @ 5.0GT/s
pci7 at ppb6 bus 7
ppb7 at pci2 dev 4 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb7: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x2 @ 5.0GT/s
pci8 at ppb7 bus 8
aq0 at pci8 dev 0 function 0: Aquantia AQC100 10 Gigabit Network
Adapter (rev. 0x02)
aq0: Atlantic revision B1, F/W version 3.1.58
aq0: Etheraddr:
ppb8 at pci2 dev 6 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb8: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x1 @ 5.0GT/s
pci9 at ppb8 bus 9
ppb9 at pci2 dev 7 function 0: AMD 300 Series PCIe (rev. 0x02)
ppb9: PCI Express capability version 2 <Downstream Port of PCI-E
Switch> x1 @ 5.0GT/s
ppb9: link is x1 @ 2.5GT/s
pci10 at ppb9 bus 10
athn0 at pci10 dev 0 function 0: Atheros AR9287
pchb1 at pci0 dev 2 function 0: AMD product 1482 (rev. 0x00)
pchb2 at pci0 dev 3 function 0: AMD product 1482 (rev. 0x00)
ppb10 at pci0 dev 3 function 1: AMD product 1483 (rev. 0x00)
ppb10: PCI Express capability version 2 <Root Port of PCI-E Root
Complex> x16 @ 8.0GT/s
pci11 at ppb10 bus 11
radeon0 at pci11 dev 0 function 0: ATI Technologies product 6811 (rev. 0x81)
hdaudio0 at pci11 dev 0 function 1: HD Audio Controller
hdaudio0: interrupting at msi3 vec 0
hdaudio0: HDA ver. 1.0, OSS 6, ISS 0, BSS 0, SDO 2, 64-bit
hdafg0 at hdaudio0: vendor 1002 product aa01
hdafg0: HDMI00 2ch: Digital Out [Jack]
hdafg0: HDMI01 2ch: Digital Out [Jack]
hdafg0: HDMI02 2ch: Digital Out [Jack]
hdafg0: HDMI03 2ch: Digital Out [Jack]
hdafg0: HDMI04 2ch: Digital Out [Jack]
hdafg0: HDMI05 2ch: Digital Out [Jack]
hdafg0: 2ch/0ch 32000Hz 44100Hz 48000Hz PCM16 AC3
pchb3 at pci0 dev 4 function 0: AMD product 1482 (rev. 0x00)
pchb4 at pci0 dev 5 function 0: AMD product 1482 (rev. 0x00)
pchb5 at pci0 dev 7 function 0: AMD product 1482 (rev. 0x00)
ppb11 at pci0 dev 7 function 1: AMD product 1484 (rev. 0x00)
ppb11: PCI Express capability version 2 <Root Port of PCI-E Root
Complex> x16 @ 16.0GT/s
pci12 at ppb11 bus 12
AMD product 148a (non-essential instrumentation, subclass 0x00) at
pci12 dev 0 function 0 not configured
pchb6 at pci0 dev 8 function 0: AMD product 1482 (rev. 0x00)
ppb12 at pci0 dev 8 function 1: AMD product 1484 (rev. 0x00)
ppb12: PCI Express capability version 2 <Root Port of PCI-E Root
Complex> x16 @ 16.0GT/s
pci13 at ppb12 bus 13
AMD Family17h/7xh Reserved SPP (non-essential instrumentation,
subclass 0x00) at pci13 dev 0 function 0 not configured
amdccp0 at pci13 dev 0 function 1: AMD Cryptographic Coprocessor
xhci1 at pci13 dev 0 function 3: AMD Family17h/7xh USB 3.0 Host
Controller (rev. 0x00)
xhci1: interrupting at msix4 vec 0
usb2 at xhci1: USB revision 3.1
usb3 at xhci1: USB revision 2.0
hdaudio1 at pci13 dev 0 function 4: HD Audio Controller
hdaudio1: interrupting at msi5 vec 0
hdaudio1: HDA ver. 1.0, OSS 4, ISS 4, BSS 0, SDO 1, 64-bit
hdafg1 at hdaudio1: vendor 10ec product 0892
hdafg1: DAC00 8ch: Speaker [Jack]
hdafg1: DAC01 2ch: HP Out [Jack]
hdafg1: DIG02 2ch: SPDIF Out [Jack]
hdafg1: ADC03 2ch: Line In [Jack], Mic In [Jack]
hdafg1: ADC04 2ch: Mic In [Jack]
hdafg1: 8ch/2ch 32000Hz 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz PCM16
PCM20 PCM24 AC3
audio0 at hdafg1: playback, capture, full duplex, independent
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording
spkr1 at audio0: PC Speaker (synthesized)
wsbell at spkr1 not configured
ppb13 at pci0 dev 8 function 2: AMD product 1484 (rev. 0x00)
ppb13: PCI Express capability version 2 <Root Port of PCI-E Root
Complex> x16 @ 16.0GT/s
pci14 at ppb13 bus 14
ahcisata1 at pci14 dev 0 function 0: AMD FCH AHCI (rev. 0x51)
ahcisata1: AHCI revision 1.31, 8 ports, 32 slots, CAP
0xf737ff07<PSC,SSC,PMD,FBSS,SPM,SAM,ISS=0x3=Gen3,SCLO,SAL,SALP,SMPS,SSNTF,SNCQ,S64A>
ahcisata1: interrupting at msi6 vec 0
atabus8 at ahcisata1 channel 0
atabus9 at ahcisata1 channel 1
atabus10 at ahcisata1 channel 2
atabus11 at ahcisata1 channel 3
atabus12 at ahcisata1 channel 4
atabus13 at ahcisata1 channel 5
atabus14 at ahcisata1 channel 6
atabus15 at ahcisata1 channel 7
ppb14 at pci0 dev 8 function 3: AMD product 1484 (rev. 0x00)
ppb14: PCI Express capability version 2 <Root Port of PCI-E Root
Complex> x16 @ 16.0GT/s
pci15 at ppb14 bus 15
ahcisata2 at pci15 dev 0 function 0: AMD FCH AHCI (rev. 0x51)
ahcisata2: AHCI revision 1.31, 8 ports, 32 slots, CAP
0xf737ff07<PSC,SSC,PMD,FBSS,SPM,SAM,ISS=0x3=Gen3,SCLO,SAL,SALP,SMPS,SSNTF,SNCQ,S64A>
ahcisata2: interrupting at msi7 vec 0
atabus16 at ahcisata2 channel 0
atabus17 at ahcisata2 channel 1
atabus18 at ahcisata2 channel 2
atabus19 at ahcisata2 channel 3
atabus20 at ahcisata2 channel 4
atabus21 at ahcisata2 channel 5
atabus22 at ahcisata2 channel 6
atabus23 at ahcisata2 channel 7
piixpm0 at pci0 dev 20 function 0: AMD X370/X399 SMBus Controller (rev. 0x61)
piixpm0: interrupting at SMI,
iic0 at piixpm0 port 0: I2C bus
iic1 at piixpm0 port 1: I2C bus
pcib0 at pci0 dev 20 function 3: AMD FCH LPC (rev. 0x51)
pchb7 at pci0 dev 24 function 0: AMD product 1440 (rev. 0x00)
pchb8 at pci0 dev 24 function 1: AMD product 1441 (rev. 0x00)
pchb9 at pci0 dev 24 function 2: AMD product 1442 (rev. 0x00)
pchb10 at pci0 dev 24 function 3: AMD product 1443 (rev. 0x00)
pchb11 at pci0 dev 24 function 4: AMD product 1444 (rev. 0x00)
pchb12 at pci0 dev 24 function 5: AMD product 1445 (rev. 0x00)
pchb13 at pci0 dev 24 function 6: AMD product 1446 (rev. 0x00)
pchb14 at pci0 dev 24 function 7: AMD product 1447 (rev. 0x00)
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, 1-byte FIFO
com0: console
acpicpu0 at cpu0: ACPI CPU
acpicpu1 at cpu1: ACPI CPU
acpicpu2 at cpu2: ACPI CPU
acpicpu3 at cpu3: ACPI CPU
acpicpu4 at cpu4: ACPI CPU
acpicpu5 at cpu5: ACPI CPU
acpicpu6 at cpu6: ACPI CPU
acpicpu7 at cpu7: ACPI CPU
acpicpu8 at cpu8: ACPI CPU
acpicpu9 at cpu9: ACPI CPU
acpicpu10 at cpu10: ACPI CPU
acpicpu11 at cpu11: ACPI CPU
cpu0 has 2 core siblings: cpu6 cpu0
cpu0 has 12 pkg siblings: cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9
cpu10 cpu11 cpu0
cpu0 has 1 1st siblings: cpu0
cpu0 first in package: cpu0
cpu1 has 2 core siblings: cpu7 cpu1
cpu1 has 12 pkg siblings: cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9
cpu10 cpu11 cpu0 cpu1
cpu1 has 1 1st siblings: cpu0
cpu1 first in package: cpu0
cpu2 has 2 core siblings: cpu8 cpu2
cpu2 has 12 pkg siblings: cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9 cpu10
cpu11 cpu0 cpu1 cpu2
cpu2 has 1 1st siblings: cpu0
cpu2 first in package: cpu0
cpu3 has 2 core siblings: cpu9 cpu3
cpu3 has 12 pkg siblings: cpu4 cpu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11
cpu0 cpu1 cpu2 cpu3
cpu3 has 1 1st siblings: cpu0
cpu3 first in package: cpu0
cpu4 has 2 core siblings: cpu10 cpu4
cpu4 has 12 pkg siblings: cpu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu0
cpu1 cpu2 cpu3 cpu4
cpu4 has 1 1st siblings: cpu0
cpu4 first in package: cpu0
cpu5 has 2 core siblings: cpu11 cpu5
cpu5 has 12 pkg siblings: cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu0 cpu1
cpu2 cpu3 cpu4 cpu5
cpu5 has 1 1st siblings: cpu0
cpu5 first in package: cpu0
cpu6 has 2 core siblings: cpu0 cpu6
cpu6 has 12 pkg siblings: cpu7 cpu8 cpu9 cpu10 cpu11 cpu0 cpu1 cpu2
cpu3 cpu4 cpu5 cpu6
cpu6 has 1 1st siblings: cpu0
cpu6 first in package: cpu0
cpu7 has 2 core siblings: cpu1 cpu7
cpu7 has 12 pkg siblings: cpu8 cpu9 cpu10 cpu11 cpu0 cpu1 cpu2 cpu3
cpu4 cpu5 cpu6 cpu7
cpu7 has 1 1st siblings: cpu0
cpu7 first in package: cpu0
cpu8 has 2 core siblings: cpu2 cpu8
cpu8 has 12 pkg siblings: cpu9 cpu10 cpu11 cpu0 cpu1 cpu2 cpu3 cpu4
cpu5 cpu6 cpu7 cpu8
cpu8 has 1 1st siblings: cpu0
cpu8 first in package: cpu0
cpu9 has 2 core siblings: cpu3 cpu9
cpu9 has 12 pkg siblings: cpu10 cpu11 cpu0 cpu1 cpu2 cpu3 cpu4 cpu5
cpu6 cpu7 cpu8 cpu9
cpu9 has 1 1st siblings: cpu0
cpu9 first in package: cpu0
cpu10 has 2 core siblings: cpu4 cpu10
cpu10 has 12 pkg siblings: cpu11 cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6
cpu7 cpu8 cpu9 cpu10
cpu10 has 1 1st siblings: cpu0
cpu10 first in package: cpu0
cpu11 has 2 core siblings: cpu5 cpu11
cpu11 has 12 pkg siblings: cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7
cpu8 cpu9 cpu10 cpu11
cpu11 has 1 1st siblings: cpu0
cpu11 first in package: cpu0
athn0: link state DOWN (was UNKNOWN)
uhub0 at usb0: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev
3.00/1.00, addr 0
uhub1 at usb1: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev
2.00/1.00, addr 0
uhub2 at usb2: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev
3.00/1.00, addr 0
uhub3 at usb3: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev
2.00/1.00, addr 0
ahcisata0 port 1: device present, speed: 3.0Gb/s
ahcisata0 port 0: device present, speed: 6.0Gb/s
ahcisata0 port 5: device present, speed: 1.5Gb/s
umass0 at uhub0 port 2 configuration 1 interface 0
umass0: ADATA (0x125f) ADATA USB Flash Drive (0xdd1a), rev 3.00/11.00, addr 1
wd0 at atabus0 drive 0
wd0: <KINGSTON SKC400S37512G>
wd0: 476 GB, 992277 cyl, 16 head, 63 sec, 512 bytes/sect x 1000215216 sectors
wd1 at atabus1 drive 0
uhub4 at uhub1 port 12: vendor 0424 (0x0424) product 2504 (0x2504),
class 9/0, rev 2.00/0.01, addr 2
uhub4: multiple transaction translators
wd1: <SAMSUNG HD161HJ>
wd1: 149 GB, 310101 cyl, 16 head, 63 sec, 512 bytes/sect x 312581808 sectors
ubt0 at uhub3 port 2
ubt0: vendor 0a12 (0x0a12) BT DONGLE10 (0x0001), rev 2.00/88.91, addr 1
scsibus0 at umass0: 2 targets, 1 lun per target
atapibus0 at atabus5: 1 targets
cd0 at atapibus0 drive 0: <HL-DT-ST DVDRAM GH22NS40, K5I98JK5513,
NL01> cdrom removable
sd0 at scsibus0 target 0 lun 0: <ADATA, USB Flash Drive, 1100> disk removable
sd0: fabricating a geometry
sd0: 29600 MB, 29600 cyl, 64 head, 32 sec, 512 bytes/sect x 60620800 sectors
sd0: fabricating a geometry
panic: kernel diagnostic assertion "addr >= 1 && addr <= 127" failed:
file "/home/andriusv/workspace/netbsd-src/sys/dev/usb/xhci.c", line
2901 addr 0
cpu2: Begin traceback...
vpanic() at netbsd:vpanic+0x156
__x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax
xhci_new_device() at netbsd:xhci_new_device+0x6be
uhub_explore() at netbsd:uhub_explore+0x2ef
uhub_explore() at netbsd:uhub_explore+0x96
usb_discover() at netbsd:usb_discover+0xa1
usb_event_thread() at netbsd:usb_event_thread+0x3c
cpu2: End traceback...
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 0xffffffff80221a35 cs 0x8 rflags 0x202 cr2 0
ilevel 0 rsp 0xffffcd826e20bd70
curlwp 0xffff96dab93a2740 pid 0.391 lowest kstack 0xffffcd826e2072c0
Stopped in pid 0.391 (system) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x156
__x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax
xhci_new_device() at netbsd:xhci_new_device+0x6be
uhub_explore() at netbsd:uhub_explore+0x2ef
uhub_explore() at netbsd:uhub_explore+0x96
usb_discover() at netbsd:usb_discover+0xa1
usb_event_thread() at netbsd:usb_event_thread+0x3c
ds ffff
es 2
fs bd80
gs bd20
rdi 0
rsi 3f8
rbp ffffcd826e20bd70
rbx 3
rdx 1
rcx 0
rax 0
r8 3
r9 7
r10 ffffcd826e20bce0
r11 10
r12 ffffffff813d3388 ostype+0x85b48
r13 ffffcd826e20bdb8
r14 104
r15 ffff96dab7ada990
rip ffffffff80221a35 breakpoint+0x5
cs 8
rflags 202
rsp ffffcd826e20bd70
ss 10
netbsd:breakpoint+0x5: leave
On Sun, May 23, 2021 at 8:01 PM <nia@netbsd.org> wrote:
>
> Synopsis: xhci suspend/resume is unimplemented
>
> State-Changed-From-To: feedback->closed
> State-Changed-By: nia@NetBSD.org
> State-Changed-When: Sun, 23 May 2021 17:01:00 +0000
> State-Changed-Why:
> When my machine does not lock up due to current having other resume
> regressions, this works great. Thanks!
>
>
>
From: maya@NetBSD.org
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org, nia@pkgsrc.org
Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
Date: Wed, 26 May 2021 10:41:47 +0000
On Wed, May 26, 2021 at 09:15:02AM +0000, Andrius V wrote:
> The following reply was made to PR kern/56050; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
> nia@netbsd.org, Taylor R Campbell <riastradh@netbsd.org>
> Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> Date: Wed, 26 May 2021 12:09:45 +0300
>
> The latest xhci.c rev 1.140 changes are causing panic in my system if
> any xhci device (or at least with my USB stick and/or external SSD) is
> connected. The previous commit still works (suspend/resume draft).
> Interestingly enough and probably irrelevant, the kernel does not
> crash with serial console boot on 115200 speed (still fails on default
> 9600 speed though).
>
xhci.c 1.140 only touches suspend/resume code, and you don't seem to be
suspending in this dmesg.
I suspect this is a spurious panic that happens sometimes.
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nia@pkgsrc.org
Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
Date: Wed, 26 May 2021 13:59:07 +0300
No, it happens consistently on every boot right after that commit. I
tested kernels commit by commit, all previous ones boot without
issues. Yes, I don't suspend/resume, not sure why it affects booting
process.
On Wed, May 26, 2021 at 1:45 PM <maya@netbsd.org> wrote:
>
> The following reply was made to PR kern/56050; it has been noted by GNATS.
>
> From: maya@NetBSD.org
> To: gnats-bugs@netbsd.org
> Cc: netbsd-bugs@netbsd.org, nia@pkgsrc.org
> Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> Date: Wed, 26 May 2021 10:41:47 +0000
>
> On Wed, May 26, 2021 at 09:15:02AM +0000, Andrius V wrote:
> > The following reply was made to PR kern/56050; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: gnats-bugs@netbsd.org
> > Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
> > nia@netbsd.org, Taylor R Campbell <riastradh@netbsd.org>
> > Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> > Date: Wed, 26 May 2021 12:09:45 +0300
> >
> > The latest xhci.c rev 1.140 changes are causing panic in my system if
> > any xhci device (or at least with my USB stick and/or external SSD) is
> > connected. The previous commit still works (suspend/resume draft).
> > Interestingly enough and probably irrelevant, the kernel does not
> > crash with serial console boot on 115200 speed (still fails on default
> > 9600 speed though).
> >
>
> xhci.c 1.140 only touches suspend/resume code, and you don't seem to be
> suspending in this dmesg.
>
> I suspect this is a spurious panic that happens sometimes.
>
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nia@pkgsrc.org, Taylor R Campbell <riastradh@netbsd.org>
Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
Date: Thu, 27 May 2021 01:07:55 +0300
--0000000000008cf4f505c342e006
Content-Type: text/plain; charset="UTF-8"
The main suspicion came for me on while loop condition changes starting
line 3198:
while (sc->sc_command_addr != 0 &&
sc->sc_suspender != NULL &&
sc->sc_suspender != curlwp)
And it seems to be actually the culprit for the issue now: seemingly it
goes into infinite loop and likely locks the device. Because of that
usbd_delay_ms() times out without "getting" new address and assertion fails
on 2901 line (as per my backtrace). I didn't have time today to check what
are the values, but removing newly added sc->sc_suspender checks makes the
system boot successfully again.
On Wed, May 26, 2021 at 1:59 PM Andrius V <vezhlys@gmail.com> wrote:
>
> No, it happens consistently on every boot right after that commit. I
> tested kernels commit by commit, all previous ones boot without
> issues. Yes, I don't suspend/resume, not sure why it affects booting
> process.
>
> On Wed, May 26, 2021 at 1:45 PM <maya@netbsd.org> wrote:
> >
> > The following reply was made to PR kern/56050; it has been noted by
GNATS.
> >
> > From: maya@NetBSD.org
> > To: gnats-bugs@netbsd.org
> > Cc: netbsd-bugs@netbsd.org, nia@pkgsrc.org
> > Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> > Date: Wed, 26 May 2021 10:41:47 +0000
> >
> > On Wed, May 26, 2021 at 09:15:02AM +0000, Andrius V wrote:
> > > The following reply was made to PR kern/56050; it has been noted by
GNATS.
> > >
> > > From: Andrius V <vezhlys@gmail.com>
> > > To: gnats-bugs@netbsd.org
> > > Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
gnats-admin@netbsd.org,
> > > nia@netbsd.org, Taylor R Campbell <riastradh@netbsd.org>
> > > Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
> > > Date: Wed, 26 May 2021 12:09:45 +0300
> > >
> > > The latest xhci.c rev 1.140 changes are causing panic in my system
if
> > > any xhci device (or at least with my USB stick and/or external SSD)
is
> > > connected. The previous commit still works (suspend/resume draft).
> > > Interestingly enough and probably irrelevant, the kernel does not
> > > crash with serial console boot on 115200 speed (still fails on
default
> > > 9600 speed though).
> > >
> >
> > xhci.c 1.140 only touches suspend/resume code, and you don't seem to be
> > suspending in this dmesg.
> >
> > I suspect this is a spurious panic that happens sometimes.
> >
--0000000000008cf4f505c342e006
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">The main suspicion came for me on while loop condition ch=
anges starting line 3198:<br>
=C2=A0 =C2=A0 while (sc->sc_command_addr !=3D 0 &&<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sc->sc_suspender !=3D NULL &&<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sc->sc_suspender !=3D curlwp)<br>
<br>
And it seems to be actually the culprit for the issue now: seemingly it goe=
s into infinite loop and likely locks the device. Because of that usbd_dela=
y_ms() times out without "getting" new address and assertion fail=
s on 2901 line (as per my backtrace). I didn't have time today to check=
what are the values, but removing newly added sc->sc_suspender checks m=
akes the system boot successfully again.</div><br>
<br>
On Wed, May 26, 2021 at 1:59 PM Andrius V <<a href=3D"mailto:vezhlys@gma=
il.com" target=3D"_blank" rel=3D"noreferrer">vezhlys@gmail.com</a>> wrot=
e:<br>
><br>
> No, it happens consistently on every boot right after that commit. I<b=
r>
> tested kernels commit by commit, all previous ones boot without<br>
> issues. Yes, I don't suspend/resume, not sure why it affects booti=
ng<br>
> process.<br>
><br>
> On Wed, May 26, 2021 at 1:45 PM <<a href=3D"mailto:maya@netbsd.org"=
target=3D"_blank" rel=3D"noreferrer">maya@netbsd.org</a>> wrote:<br>
> ><br>
> > The following reply was made to PR kern/56050; it has been noted =
by GNATS.<br>
> ><br>
> > From: maya@NetBSD.org<br>
> > To: <a href=3D"mailto:gnats-bugs@netbsd.org" target=3D"_blank" re=
l=3D"noreferrer">gnats-bugs@netbsd.org</a><br>
> > Cc: <a href=3D"mailto:netbsd-bugs@netbsd.org" target=3D"_blank" r=
el=3D"noreferrer">netbsd-bugs@netbsd.org</a>, <a href=3D"mailto:nia@pkgsrc.=
org" target=3D"_blank" rel=3D"noreferrer">nia@pkgsrc.org</a><br>
> > Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)<br=
>
> > Date: Wed, 26 May 2021 10:41:47 +0000<br>
> ><br>
> >=C2=A0 On Wed, May 26, 2021 at 09:15:02AM +0000, Andrius V wrote:<=
br>
> >=C2=A0 > The following reply was made to PR kern/56050; it has =
been noted by GNATS.<br>
> >=C2=A0 ><br>
> >=C2=A0 > From: Andrius V <<a href=3D"mailto:vezhlys@gmail.co=
m" target=3D"_blank" rel=3D"noreferrer">vezhlys@gmail.com</a>><br>
> >=C2=A0 > To: <a href=3D"mailto:gnats-bugs@netbsd.org" target=3D=
"_blank" rel=3D"noreferrer">gnats-bugs@netbsd.org</a><br>
> >=C2=A0 > Cc: <a href=3D"mailto:kern-bug-people@netbsd.org" targ=
et=3D"_blank" rel=3D"noreferrer">kern-bug-people@netbsd.org</a>, <a href=3D=
"mailto:netbsd-bugs@netbsd.org" target=3D"_blank" rel=3D"noreferrer">netbsd=
-bugs@netbsd.org</a>, <a href=3D"mailto:gnats-admin@netbsd.org" target=3D"_=
blank" rel=3D"noreferrer">gnats-admin@netbsd.org</a>,<br>
> >=C2=A0 >=C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:nia@netbsd.org" =
target=3D"_blank" rel=3D"noreferrer">nia@netbsd.org</a>, Taylor R Campbell =
<<a href=3D"mailto:riastradh@netbsd.org" target=3D"_blank" rel=3D"norefe=
rrer">riastradh@netbsd.org</a>><br>
> >=C2=A0 > Subject: Re: kern/56050 (xhci suspend/resume is unimpl=
emented)<br>
> >=C2=A0 > Date: Wed, 26 May 2021 12:09:45 +0300<br>
> >=C2=A0 ><br>
> >=C2=A0 >=C2=A0 The latest xhci.c rev 1.140 changes are causing =
panic in my system if<br>
> >=C2=A0 >=C2=A0 any xhci device (or at least with my USB stick a=
nd/or external SSD) is<br>
> >=C2=A0 >=C2=A0 connected. The previous commit still works (susp=
end/resume draft).<br>
> >=C2=A0 >=C2=A0 Interestingly enough and probably irrelevant, th=
e kernel does not<br>
> >=C2=A0 >=C2=A0 crash with serial console boot on 115200 speed (=
still fails on default<br>
> >=C2=A0 >=C2=A0 9600 speed though).<br>
> >=C2=A0 ><br>
> ><br>
> >=C2=A0 xhci.c 1.140 only touches suspend/resume code, and you don&=
#39;t seem to be<br>
> >=C2=A0 suspending in this dmesg.<br>
> ><br>
> >=C2=A0 I suspect this is a spurious panic that happens sometimes.<=
br>
> ><br>
--0000000000008cf4f505c342e006--
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56050 CVS commit: src/sys/dev/usb
Date: Wed, 26 May 2021 22:37:21 +0000
Module Name: src
Committed By: riastradh
Date: Wed May 26 22:37:21 UTC 2021
Modified Files:
src/sys/dev/usb: xhci.c
Log Message:
xhci: Fix logic in waiting for command queue access.
_Either_ an existing command in progress, _or_ an existing suspend in
progress that is not done by us, should block us; the logic I wrote
previously erroneously blocked only if both conditions happened at
the same time.
Should fix issue reported by Andrius V in the PR kern/56050 followup
discussion.
To generate a diff of this commit:
cvs rdiff -u -r1.140 -r1.141 src/sys/dev/usb/xhci.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nia@pkgsrc.org
Subject: Re: PR/56050 CVS commit: src/sys/dev/usb
Date: Thu, 27 May 2021 09:50:49 +0300
Yes, it fixes an issue. Thank you.
On Thu, May 27, 2021 at 1:40 AM Taylor R Campbell <riastradh@netbsd.org> wrote:
>
> The following reply was made to PR kern/56050; it has been noted by GNATS.
>
> From: "Taylor R Campbell" <riastradh@netbsd.org>
> To: gnats-bugs@gnats.NetBSD.org
> Cc:
> Subject: PR/56050 CVS commit: src/sys/dev/usb
> Date: Wed, 26 May 2021 22:37:21 +0000
>
> Module Name: src
> Committed By: riastradh
> Date: Wed May 26 22:37:21 UTC 2021
>
> Modified Files:
> src/sys/dev/usb: xhci.c
>
> Log Message:
> xhci: Fix logic in waiting for command queue access.
>
> _Either_ an existing command in progress, _or_ an existing suspend in
> progress that is not done by us, should block us; the logic I wrote
> previously erroneously blocked only if both conditions happened at
> the same time.
>
> Should fix issue reported by Andrius V in the PR kern/56050 followup
> discussion.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.140 -r1.141 src/sys/dev/usb/xhci.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: PR/56050 CVS commit: src/sys/dev/usb
Date: Fri, 4 Jun 2021 16:24:19 +0000
On Wed, May 26, 2021 at 10:40:02PM +0000, Taylor R Campbell wrote:
> Modified Files:
> src/sys/dev/usb: xhci.c
>
> Log Message:
> xhci: Fix logic in waiting for command queue access.
>
> _Either_ an existing command in progress, _or_ an existing suspend in
> progress that is not done by us, should block us; the logic I wrote
> previously erroneously blocked only if both conditions happened at
> the same time.
>
> Should fix issue reported by Andrius V in the PR kern/56050 followup
> discussion.
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.140 -r1.141 src/sys/dev/usb/xhci.c
John Klos also wrote in to say that this fixed the problem on his rpi
4, but gnats bobbled the message.
--
David A. Holland
dholland@netbsd.org
State-Changed-From-To: closed->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 04 Jun 2021 16:28:09 +0000
State-Changed-Why:
should have been reopened when the fix blew up
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 04 Jun 2021 16:28:19 +0000
State-Changed-Why:
really fixed now
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
Date: Fri, 4 Jun 2021 18:07:22 +0000
Do we want this pulled up?
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56050 (xhci suspend/resume is unimplemented)
Date: Fri, 4 Jun 2021 18:21:13 +0000
On Fri, Jun 04, 2021 at 06:10:02PM +0000, nia wrote:
> Do we want this pulled up?
You filed in on -current, so by the usual procedure no, but if it
applies and works and isn't invasive it seems like it might be
worthwhile.
--
David A. Holland
dholland@netbsd.org
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56050 CVS commit: [netbsd-9] src/sys/dev/usb
Date: Mon, 21 Jun 2021 17:11:46 +0000
Module Name: src
Committed By: martin
Date: Mon Jun 21 17:11:46 UTC 2021
Modified Files:
src/sys/dev/usb [netbsd-9]: xhci.c xhcireg.h xhcivar.h
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1301):
sys/dev/usb/xhci.c: revision 1.140
sys/dev/usb/xhci.c: revision 1.141
sys/dev/usb/xhci.c: revision 1.143
sys/dev/usb/xhcivar.h: revision 1.18
sys/dev/usb/xhcivar.h: revision 1.19
sys/dev/usb/xhcireg.h: revision 1.19
sys/dev/usb/xhci.c: revision 1.139
xhci(4): Draft suspend/resume.
Work almost entirely done and tested by maya@ based on xhci 1.2 spec;
tidied up and tweaked by me.
Not sure about issuing Stop Endpoint commands or ensuring the Command
Ring is in the Stopped or Idle state, but this seems to work as is,
so it's already an improvement over what we had before which was no
xhci suspend/resume at all.
In particular, it's not clear to us:
- if we don't have any pending USB activity whether we need to issue
the Stop Endpoints or quiesce the command ring; but
- if we do have any pending USB activity whether issuing Stop
Endpoint is enough or whether we also need to do anything to
synchronize with other software logic to quiesce it too.
xhci(4): Block commands and issue Stop Endpoint on suspend.
xhci: Fix logic in waiting for command queue access.
_Either_ an existing command in progress, _or_ an existing suspend in
progress that is not done by us, should block us; the logic I wrote
previously erroneously blocked only if both conditions happened at
the same time.
Should fix issue reported by Andrius V in the PR kern/56050 followup
discussion.
xhci(4): Wait USB_RESUME_WAIT ms, not 20 ms.
Better to use the named constant, and although the spec says 20 ms is
enough, apparently for some devices it's not.
To generate a diff of this commit:
cvs rdiff -u -r1.107.2.7 -r1.107.2.8 src/sys/dev/usb/xhci.c
cvs rdiff -u -r1.13 -r1.13.2.1 src/sys/dev/usb/xhcireg.h
cvs rdiff -u -r1.11 -r1.11.4.1 src/sys/dev/usb/xhcivar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home