[Bug 276587] ccp(4) causes 'sysctl -a' to hang when reading OID 'kern.geom.conftxt'
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 276587] ccp(4) causes 'sysctl -a' to hang when reading OID 'kern.geom.conftxt'"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 276587] ccp(4) causes 'sysctl -a' to hang when reading OID 'kern.geom.conftxt'"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 276587] ccp(4) causes 'sysctl -a' to hang when reading OID 'kern.geom.conftxt'"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 276587] ccp(4) causes 'sysctl -a' to hang when reading OID 'kern.geom.conftxt'"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 276587] ccp(4) causes 'sysctl -a' to hang when reading OID 'kern.geom.conftxt'"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 24 Jan 2024 15:10:32 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276587
Bug ID: 276587
Summary: ccp(4) causes 'sysctl -a' to hang when reading OID
'kern.geom.conftxt'
Product: Base System
Version: 14.0-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: freebsd@kumba.dev
The ccp(4) driver appears to work on my NAS machine's Ryzen 5 2200G a bit
better under 14.0-RELEASE, in that GELI can create encrypted swap w/o hanging
and as far as I can tell, that swap seems to work. However, attempting to dump
all sysctl values w/ 'sysctl -a' will cause sysctl to do a hard hang when it
gets to OID 'kern.geom.conftxt'. The process becomes unresponsive and cannot
be exited w/ ctrl+c, or killed by any signals, including SIGKILL. It goes into
the D+ state and only a reboot can clear it.
Sample output from truss showing the hang-up on 'kern.geom.conftxt':
> 42815: 0.000007549 write(1,"\n",1) = 1 (0x1)
> 42815: 0.000007590 __sysctl("sysctl.next",5,0x45a51ae7830,0x45a51ae7828,0x0,0) = 0 (0x0)
> 42815: 0.000010670 __sysctl("sysctl.name { 1.2147483316.2147483313 }",5,0x45a51ae6f70,0x45a51ae6af0,0x0,0) = 0 (0x0)
> 42815: 0.000008760 __sysctl("sysctl.oidfmt kern.geom.conftxt",5,0x45a51ae73e0,0x45a51ae6af8,0x0,0) = 0 (0x0)
> ^C^C
Some dmesg/pciconf info, in case it helps:
dmesg:
> # dmesg | grep ccp
> ccp0: <AMD CCP-5a> mem 0xfc700000-0xfc7fffff,0xfc884000-0xfc885fff irq 54 at device 0.2 on pci10
> [26] GEOM_ELI: Device da0p2.eli created.
> [26] GEOM_ELI: Encryption: AES-XTS 256
> [26] GEOM_ELI: Crypto: hardware
pciconf -lvcV
ccp0@pci0:10:0:2: class=0x108000 rev=0x00 hdr=0x00 vendor=0x1022
device=0x15df subvendor=0x1043 subdevice=0x876b
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 10h-1fh) Platform Security Processor'
class = encrypt/decrypt
cap 09[48] = vendor (length 8)
cap 01[50] = powerspec 3 supports D0 D3 current D0
cap 10[64] = PCI-Express 2 endpoint max data 256(256) RO NS
max read 512
link x16(x16) speed 8.0(8.0) ASPM disabled(L0s/L1)
cap 05[a0] = MSI supports 2 messages, 64 bit
cap 11[c0] = MSI-X supports 2 messages, enabled
Table in map 0x24[0x0], PBA in map 0x24[0x1000]
ecap 000b[100] = Vendor [1] ID 0001 Rev 1 Length 16
--
You are receiving this mail because:
You are the assignee for the bug.