Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #72279 > unrolled thread
| Started by | Nathaniel Wesley Filardo <nwfilardo@gmail.com> |
|---|---|
| First post | 2021-06-24 15:20 +0200 |
| Last post | 2022-03-09 21:10 +0100 |
| Articles | 17 — 6 participants |
Back to article view | Back to linux.debian.kernel
Bug#990279: linux-image-5.10.0-7-powerpc64le: Upgrade to 5.10.0-7-powerpc64le from 5.10.0-0.bpo.5-powerpc64le breaks amdgpu Nathaniel Wesley Filardo <nwfilardo@gmail.com> - 2021-06-24 15:20 +0200
Bug#990279: Also affects stable... Timothy Pearson <tpearson@raptorengineering.com> - 2021-07-25 07:00 +0200
Bug#990279: Also affects stable... Timothy Pearson <tpearson@raptorengineering.com> - 2021-07-25 23:20 +0200
Bug#990279: linux-image-5.10.0-7-powerpc64le: Upgrade to 5.10.0-7-powerpc64le from 5.10.0-0.bpo.5-powerpc64le breaks amdgpu Nathaniel Filardo <nwfilardo@gmail.com> - 2021-08-10 03:30 +0200
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? Nathaniel Filardo <nwfilardo@gmail.com> - 2021-10-10 16:00 +0200
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? Xi Ruoyao <xry111@mengyan1223.wang> - 2021-10-10 16:30 +0200
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? Salvatore Bonaccorso <carnil@debian.org> - 2021-10-13 22:20 +0200
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? Salvatore Bonaccorso <carnil@debian.org> - 2021-10-30 16:40 +0200
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? Nathaniel Filardo <nwfilardo@gmail.com> - 2022-01-28 00:10 +0100
Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? Andrew <akaminski@mailfence.com> - 2022-01-29 00:20 +0100
Bug#990279: Status? Timothy Pearson <tpearson@raptorengineering.com> - 2022-02-08 20:40 +0100
Bug#990279: Status? Salvatore Bonaccorso <carnil@debian.org> - 2022-02-08 22:30 +0100
Bug#990279: Status? Timothy Pearson <tpearson@raptorengineering.com> - 2022-02-08 22:30 +0100
Bug#990279: Status? Timothy Pearson <tpearson@raptorengineering.com> - 2022-02-09 20:30 +0100
Bug#990279: Status? Salvatore Bonaccorso <carnil@debian.org> - 2022-02-09 21:30 +0100
Bug#990279: Status? Timothy Pearson <tpearson@raptorengineering.com> - 2022-02-09 21:30 +0100
Bug#990279: Status? Andrew <akaminski@mailfence.com> - 2022-03-09 21:10 +0100
| From | Nathaniel Wesley Filardo <nwfilardo@gmail.com> |
|---|---|
| Date | 2021-06-24 15:20 +0200 |
| Subject | Bug#990279: linux-image-5.10.0-7-powerpc64le: Upgrade to 5.10.0-7-powerpc64le from 5.10.0-0.bpo.5-powerpc64le breaks amdgpu |
| Message-ID | <Ctxhf-3p8-1@gated-at.bofh.it> |
Package: src:linux
Version: 5.10.40-1
Severity: normal
X-Debbugs-Cc: nwfilardo@gmail.com
Dear Maintainer,
Upgrading from 5.10.0-0.bpo.5-powerpc64le=5.10.24-1~bpo10+1 to
5.10.0-7-powerpc64le=5.10.40-1 has broken my X server's ability to use GL, and
has, indeed, lead to markedly poor performance even in things like rxvt.
Quoting /var/log/Xorg.0.log:
[ 19.084] (II) LoadModule: "glx"
[ 19.087] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 19.102] (II) Module glx: vendor="X.Org Foundation"
[ 19.143] (II) Loading sub module "glamoregl"
[ 19.143] (II) LoadModule: "glamoregl"
[ 19.143] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[ 19.159] (II) Module glamoregl: vendor="X.Org Foundation"
[ 19.573] (II) modeset(0): glamor X acceleration enabled on AMD Radeon (TM) Pro WX 7100 Graphics (POLARIS10, DRM 3.40.0, 5.10.0-7-powerpc64le, LLVM 11.0.1)
[ 19.573] (II) modeset(0): glamor initialized
[ 19.647] (II) Initializing extension GLX
[ 19.656] (II) AIGLX: Loaded and initialized radeonsi
[ 19.656] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 20.985] (EE) glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage
[ 21.018] (WW) glamor: Failed to allocate 48x48 FBO due to GL_OUT_OF_MEMORY.
[ 21.018] (WW) glamor: Expect reduced performance.
Things work just fine with the same machine on the old kernel, so I'm holding
back for now, but this isn't a great long-term solution. This is a Talos II
workstation, making it a little niche and therefore unsurprising that
regressions have crept in, but it'd be nice to get them resolved. Any
suggestions, advice, requests for further information, &c are all appreciated.
I can rebuild kernels and bisect if pointed at the right git repository and
tags, if that'd be a useful thing.
FWIW, the same thing happened, I believe, with 5.10.0-6-powerpc64le, previously,
but I no longer have it installed to check again.
Thanks much in advance,
--nwf;
-- Package-specific info:
** Version:
Linux version 5.10.0-7-powerpc64le (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.40-1 (2021-05-28)
** Command line:
root=ZFS=rpool/ROOT/debian ro quiet
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 5.306593] [drm] amdgpu kernel modesetting enabled.
[ 5.309579] amdgpu 0030:01:00.0: vgaarb: deactivate vga console
[ 5.309753] amdgpu 0030:01:00.0: enabling device (0140 -> 0142)
[ 5.309767] amdgpu 0030:01:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported
[ 5.644486] amdgpu 0030:01:00.0: amdgpu: Fetched VBIOS from ROM BAR
[ 5.644492] amdgpu: ATOM BIOS: 113-C9540101-103
[ 5.647802] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_mc.bin
[ 5.647819] amdgpu 0030:01:00.0: BAR 2: releasing [mem 0x6200010000000-0x62000101fffff 64bit pref]
[ 5.647822] amdgpu 0030:01:00.0: BAR 0: releasing [mem 0x6200000000000-0x620000fffffff 64bit pref]
[ 5.647869] amdgpu 0030:01:00.0: BAR 0: assigned [mem 0x6200000000000-0x62001ffffffff 64bit pref]
[ 5.647879] amdgpu 0030:01:00.0: BAR 2: assigned [mem 0x6200200000000-0x62002001fffff 64bit pref]
[ 5.647913] amdgpu 0030:01:00.0: amdgpu: VRAM: 8192M 0x000000F400000000 - 0x000000F5FFFFFFFF (8192M used)
[ 5.647916] amdgpu 0030:01:00.0: amdgpu: GART: 256M 0x000000FF00000000 - 0x000000FF0FFFFFFF
[ 5.648123] [drm] amdgpu: 8192M of VRAM memory ready
[ 5.648128] [drm] amdgpu: 8192M of GTT memory ready.
[ 5.649983] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_pfp_2.bin
[ 5.650921] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_me_2.bin
[ 5.651856] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_ce_2.bin
[ 5.652822] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_rlc.bin
[ 5.654748] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_mec_2.bin
[ 5.657197] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_mec2_2.bin
[ 5.659428] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_sdma.bin
[ 5.661056] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_sdma1.bin
[ 5.661159] amdgpu: hwmgr_sw_init smu backed is polaris10_smu
[ 5.663358] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_uvd.bin
[ 5.666276] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_vce.bin
[ 5.668251] amdgpu 0030:01:00.0: firmware: direct-loading firmware amdgpu/polaris10_smc.bin
[ 5.727666] snd_hda_intel 0030:01:00.1: bound 0030:01:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
[ 5.946750] amdgpu 0030:01:00.0: amdgpu: SE 4, SH per SE 1, CU per SH 9, active_cu_number 36
[ 6.091370] amdgpu 0030:01:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[ 6.132408] [drm] Initialized amdgpu 3.40.0 20150101 for 0030:01:00.0 on minor 0
** Model information
revision : 2.2 (pvr 004e 1202)
latform : PowerNV
model : T2P9D01 REV 1.01
machine : PowerNV T2P9D01 REV 1.01
Device Tree model: T2P9D01 REV 1.01
** Loaded modules:
tun(E)
xt_conntrack(E)
nf_conntrack_netlink(E)
xfrm_user(E)
xfrm_algo(E)
xt_CHECKSUM(E)
nft_chain_nat(E)
xt_MASQUERADE(E)
nf_nat(E)
nf_conntrack(E)
nf_defrag_ipv6(E)
nf_defrag_ipv4(E)
xt_addrtype(E)
nft_counter(E)
br_netfilter(E)
xt_tcpudp(E)
nft_compat(E)
bridge(E)
stp(E)
llc(E)
nf_tables(E)
yfs(POE)
libcrc32c(E)
nfnetlink(E)
overlay(E)
binfmt_misc(E)
joydev(E)
cp210x(E)
pl2303(E)
usbserial(E)
hid_generic(E)
usbhid(E)
hid(E)
dm_crypt(E)
evdev(E)
dm_mod(E)
crc32c_generic(E)
amdgpu(E)
ecb(E)
xts(E)
ctr(E)
cbc(E)
aes_generic(E)
libaes(E)
vmx_crypto(E)
gf128mul(E)
snd_hda_codec_hdmi(E)
snd_hda_intel(E)
snd_intel_dspcfg(E)
snd_hda_codec(E)
ofpart(E)
gpu_sched(E)
snd_hda_core(E)
ipmi_powernv(E)
ttm(E)
ipmi_devintf(E)
powernv_flash(E)
snd_hwdep(E)
mtd(E)
ipmi_msghandler(E)
at24(E)
snd_pcm(E)
opal_prd(E)
drm_kms_helper(E)
tg3(E)
snd_timer(E)
regmap_i2c(E)
snd(E)
syscopyarea(E)
xhci_pci(E)
sysfillrect(E)
soundcore(E)
sysimgblt(E)
libphy(E)
fb_sys_fops(E)
xhci_hcd(E)
i2c_algo_bit(E)
ptp(E)
pps_core(E)
sg(E)
drm(E)
fuse(E)
drm_panel_orientation_quirks(E)
configfs(E)
ip_tables(E)
x_tables(E)
autofs4(E)
sd_mod(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
cdrom(E)
uas(E)
usb_storage(E)
usbcore(E)
usb_common(E)
zfs(POE)
zunicode(POE)
zzstd(OE)
zlua(OE)
zcommon(POE)
znvpair(POE)
zavl(POE)
icp(POE)
spl(OE)
nvme(E)
nvme_core(E)
t10_pi(E)
crc_t10dif(E)
crct10dif_generic(E)
crct10dif_common(E)
ahci(E)
libahci(E)
** PCI devices:
0000:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0000000/pci@0
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0001:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0100000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0001:01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) (prog-if 01 [AHCI 1.0])
Subsystem: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235]
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0100000/pci@0/sata@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 58
NUMA node: 0
IOMMU group: 0
Region 0: I/O ports at 0000
Region 1: I/O ports at 0000
Region 2: I/O ports at 0000
Region 3: I/O ports at 0000
Region 4: I/O ports at 0000
Region 5: Memory at 600c080040000 (32-bit, non-prefetchable) [size=2K]
Expansion ROM at 600c080000000 [size=256K]
Capabilities: <access denied>
Kernel driver in use: ahci
Kernel modules: ahci
0002:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0200000/pci@0
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0003:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0300000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0003:01:00.0 USB controller [0c03]: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller [104c:8241] (rev 02) (prog-if 30 [XHCI])
Subsystem: IBM S824 (8286-42A) [1014:04b2]
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0300000/pci@0/usb-xhci@0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 56
NUMA node: 0
IOMMU group: 1
Region 0: Memory at 600c180000000 (64-bit, non-prefetchable) [size=64K]
Region 2: Memory at 600c180010000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
0004:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0400000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: 0006024000000000-0006027f7fffffff [size=254G]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0004:01:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
Subsystem: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1981]
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0400000/pci@0/ethernet@0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 72
NUMA node: 0
IOMMU group: 2
Region 0: Memory at 6024000000000 (64-bit, prefetchable) [size=64K]
Region 2: Memory at 6024000010000 (64-bit, prefetchable) [size=64K]
Region 4: Memory at 6024000020000 (64-bit, prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: tg3
Kernel modules: tg3
0004:01:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
Subsystem: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1981]
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0400000/pci@0/ethernet@0,1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 73
NUMA node: 0
IOMMU group: 2
Region 0: Memory at 6024000030000 (64-bit, prefetchable) [size=64K]
Region 2: Memory at 6024000040000 (64-bit, prefetchable) [size=64K]
Region 4: Memory at 6024000050000 (64-bit, prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: tg3
Kernel modules: tg3
0005:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0500000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 0
Bus: primary=00, secondary=01, subordinate=02, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0005:01:00.0 PCI bridge [0604]: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge [1a03:1150] (rev 04) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0500000/pci@0/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 80
NUMA node: 0
Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0005:02:00.0 Multimedia video controller [0400]: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 41)
Subsystem: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000]
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0500000/pci@0/pci@0/video@0
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 80
NUMA node: 0
IOMMU group: 3
Region 0: Memory at 600c280000000 (32-bit, non-prefetchable) [disabled] [size=16M]
Region 1: Memory at 600c281000000 (32-bit, non-prefetchable) [disabled] [size=128K]
Region 2: I/O ports at <unassigned> [disabled]
Capabilities: <access denied>
0030:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0000000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 8
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: 0006200000000000-0006203fbfffffff [size=255G]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0030:01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon Pro WX 7100] [1002:67c4] (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon Pro WX 7100] [1002:0b0d]
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0000000/pci@0/vga@0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 65
NUMA node: 8
IOMMU group: 4
Region 0: Memory at 6200000000000 (64-bit, prefetchable) [size=8G]
Region 2: Memory at 6200200000000 (64-bit, prefetchable) [size=2M]
Region 4: I/O ports at <unassigned> [disabled]
Region 5: Memory at 620c000000000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at 620c000040000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: amdgpu
Kernel modules: amdgpu
0030:01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] [1002:aaf0]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] [1002:aaf0]
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0000000/pci@0/multimedia-device@0,1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 64
NUMA node: 8
IOMMU group: 4
Region 0: Memory at 620c000060000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
0031:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0100000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 8
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0031:01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961/SM963 [144d:a804] (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd SM963 2.5" NVMe PCIe SSD [144d:a801]
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0100000/pci@0/mass-storage@0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 57
NUMA node: 8
IOMMU group: 5
Region 0: Memory at 620c080000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: nvme
Kernel modules: nvme
0032:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0200000/pci@0
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 8
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:00:00.0 PCI bridge [0604]: IBM POWER9 Host Bridge (PHB4) [1014:04c1] (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
NUMA node: 8
Bus: primary=00, secondary=01, subordinate=1b, sec-latency=0
I/O behind bridge: 00000000-00000fff [size=4K]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: 0006220000000000-0006223fbfffffff [size=255G]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 9733 33-lane, 9-port PCI Express Gen 3 (8.0 GT/s) Switch [10b5:9733] (rev b0) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0/pci@0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 74
NUMA node: 8
Region 0: Memory at 620c182000000 (32-bit, non-prefetchable) [size=256K]
Bus: primary=01, secondary=02, subordinate=1b, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 80000000-ffefffff [size=2047M]
Prefetchable memory behind bridge: 0006220000000000-0006223fbfffffff [size=255G]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:02:01.0 PCI bridge [0604]: PLX Technology, Inc. PEX 9733 33-lane, 9-port PCI Express Gen 3 (8.0 GT/s) Switch [10b5:9733] (rev b0) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0/pci@0/pci@1
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 75
NUMA node: 8
Bus: primary=02, secondary=03, subordinate=07, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: [disabled]
Prefetchable memory behind bridge: [disabled]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:02:04.0 PCI bridge [0604]: PLX Technology, Inc. PEX 9733 33-lane, 9-port PCI Express Gen 3 (8.0 GT/s) Switch [10b5:9733] (rev b0) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0/pci@0/pci@4
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 74
NUMA node: 8
Bus: primary=02, secondary=08, subordinate=0c, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 80000000-803fffff [size=4M]
Prefetchable memory behind bridge: 0006220000000000-000622001fffffff [size=512M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:02:05.0 PCI bridge [0604]: PLX Technology, Inc. PEX 9733 33-lane, 9-port PCI Express Gen 3 (8.0 GT/s) Switch [10b5:9733] (rev b0) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0/pci@0/pci@5
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 75
NUMA node: 8
Bus: primary=02, secondary=0d, subordinate=11, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 80400000-807fffff [size=4M]
Prefetchable memory behind bridge: 0006220020000000-000622003fffffff [size=512M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:02:06.0 PCI bridge [0604]: PLX Technology, Inc. PEX 9733 33-lane, 9-port PCI Express Gen 3 (8.0 GT/s) Switch [10b5:9733] (rev b0) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0/pci@0/pci@6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 76
NUMA node: 8
Bus: primary=02, secondary=12, subordinate=16, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 80800000-80bfffff [size=4M]
Prefetchable memory behind bridge: 0006220040000000-000622005fffffff [size=512M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
0033:02:07.0 PCI bridge [0604]: PLX Technology, Inc. PEX 9733 33-lane, 9-port PCI Express Gen 3 (8.0 GT/s) Switch [10b5:9733] (rev b0) (prog-if 00 [Normal decode])
Device tree node: /sys/firmware/devicetree/base/pciex@620c3c0300000/pci@0/pci@0/pci@7
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 77
NUMA node: 8
Bus: primary=02, secondary=17, subordinate=1b, sec-latency=0
I/O behind bridge: [disabled]
Memory behind bridge: 80c00000-80ffffff [size=4M]
Prefetchable memory behind bridge: 0006220060000000-000622007fffffff [size=512M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
** USB devices:
Bus 002 Device 003: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 002 Device 004: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 002 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 020: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 018: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 016: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 014: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 011: ID 1b1c:0c10 Corsair Commander PRO
Bus 001 Device 008: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 007: ID 2001:f103 D-Link Corp. DUB-H7 7-port USB 2.0 hub
Bus 001 Device 019: ID 045e:0023 Microsoft Corp. Trackball Optical
Bus 001 Device 017: ID 3297:4974 ZSA Technology Labs ErgoDox EZ
Bus 001 Device 015: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 012: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 013: ID 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller
Bus 001 Device 010: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 009: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 004: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (400, 'testing'), (300, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 5.10.0-7-powerpc64le (SMP w/176 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-5.10.0-7-powerpc64le depends on:
ii initramfs-tools [linux-initramfs-tool] 0.140
ii kmod 28-1
ii linux-base 4.6
Versions of packages linux-image-5.10.0-7-powerpc64le recommends:
ii apparmor 2.13.6-10
ii firmware-linux-free 20200122-1
Versions of packages linux-image-5.10.0-7-powerpc64le suggests:
pn debian-kernel-handbook <none>
ii grub-ieee1275 2.04-18
pn linux-doc-5.10 <none>
pn mkvmlinuz <none>
Versions of packages linux-image-5.10.0-7-powerpc64le is related to:
ii firmware-amd-graphics 20210315-2
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-cavium <none>
pn firmware-intel-sound <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
pn firmware-iwlwifi <none>
pn firmware-libertas <none>
ii firmware-linux-nonfree 20210315-2
ii firmware-misc-nonfree 20210315-2
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
pn firmware-realtek <none>
pn firmware-samsung <none>
pn firmware-siano <none>
pn firmware-ti-connectivity <none>
pn xen-hypervisor <none>
-- no debconf information
[toc] | [next] | [standalone]
| From | Timothy Pearson <tpearson@raptorengineering.com> |
|---|---|
| Date | 2021-07-25 07:00 +0200 |
| Subject | Bug#990279: Also affects stable... |
| Message-ID | <CEEp3-5Fa-1@gated-at.bofh.it> |
| In reply to | #72279 |
Just hit this upgrading a stable box from 4.19.0-6-powerpc64le to 4.19.0-17-powerpc64le. AMD RX480, works perfectly again after downgrading to the older kernel.
[toc] | [prev] | [next] | [standalone]
| From | Timothy Pearson <tpearson@raptorengineering.com> |
|---|---|
| Date | 2021-07-25 23:20 +0200 |
| Subject | Bug#990279: Also affects stable... |
| Message-ID | <CETHr-6xS-5@gated-at.bofh.it> |
| In reply to | #72453 |
Reverting this patch restores the GPU to functionality:
drm/amdgpu: check alignment on CPU page for bo map
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index dc4d6ae71476..a01c158bc29f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2198,8 +2198,8 @@ int amdgpu_vm_bo_map(struct amdgpu_device *adev,
uint64_t eaddr;
/* validate the parameters */
- if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK ||
- size == 0 || size & AMDGPU_GPU_PAGE_MASK)
+ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
+ size == 0 || size & ~PAGE_MASK)
return -EINVAL;
/* make sure object fit at this offset */
@@ -2264,8 +2264,8 @@ int amdgpu_vm_bo_replace_map(struct amdgpu_device *adev,
int r;
/* validate the parameters */
- if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK ||
- size == 0 || size & AMDGPU_GPU_PAGE_MASK)
+ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK ||
+ size == 0 || size & ~PAGE_MASK)
return -EINVAL;
/* make sure object fit at this offset */
As nearly all POWER distros ship a 64k page kernel, the switch from AMDGPU_GPU_PAGE_MASK to PAGE_MASK may be at fault.
As an aside, it seems there is little to no QA for POWER desktop systems from the Debian developers. If this is due to lack of hardware access, we may be able to assist.
----- Original Message -----
> From: "Timothy Pearson" <tpearson@raptorengineering.com>
> To: "990279" <990279@bugs.debian.org>
> Sent: Saturday, July 24, 2021 11:42:02 PM
> Subject: Also affects stable...
> Just hit this upgrading a stable box from 4.19.0-6-powerpc64le to
> 4.19.0-17-powerpc64le. AMD RX480, works perfectly again after downgrading to
> the older kernel.
[toc] | [prev] | [next] | [standalone]
| From | Nathaniel Filardo <nwfilardo@gmail.com> |
|---|---|
| Date | 2021-08-10 03:30 +0200 |
| Message-ID | <CKoKB-6xp-1@gated-at.bofh.it> |
| In reply to | #72279 |
I just now noticed Timothy Pearson's note about reverting the alignment check patch. An excellent thread to start pulling on, but I don't think that is the correct fix in itself. If the addresses involved are not 64K aligned but merely 4K aligned, then the IOMMU will have to open an overly wide aperture to include the misaligned first (and possibly last) pages. This may suggest that a fix is needed in userspace to ensure proper alignment, or the misaligned addresses may be coming from somewhere else in the kernel itself. I suspect adding some WARN_ON (or perhaps WARN_ON_ONCE, just in case) will prove informative. If time permits, I'll do that, but please don't wait on me. Cheers, --nwf;
[toc] | [prev] | [next] | [standalone]
| From | Nathaniel Filardo <nwfilardo@gmail.com> |
|---|---|
| Date | 2021-10-10 16:00 +0200 |
| Subject | Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? |
| Message-ID | <D6HwR-5rU-9@gated-at.bofh.it> |
| In reply to | #72279 |
It occurs to me, quite belatedly, that it may be worth asking the author, reviewers, and signers of the change in question their thoughts on this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279 In particular, on ppc64 systems, Linux typically is configured to use a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page. It looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so something (perhaps in userspace, even, eek?) is requesting 4KiB-but-not-64KiB alignment of this buffer. Any insight you could offer would be deeply appreciated. Thanks, --nwf;
[toc] | [prev] | [next] | [standalone]
| From | Xi Ruoyao <xry111@mengyan1223.wang> |
|---|---|
| Date | 2021-10-10 16:30 +0200 |
| Subject | Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? |
| Message-ID | <D6HZU-5Qs-7@gated-at.bofh.it> |
| In reply to | #73248 |
On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote: > It occurs to me, quite belatedly, that it may be worth asking the > author, reviewers, and signers of the change in question their > thoughts on this bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279 > > In particular, on ppc64 systems, Linux typically is configured to use > a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page. It > looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so > something (perhaps in userspace, even, eek?) is requesting > 4KiB-but-not-64KiB alignment of this buffer. Christian told me the buffer should be aligned to *CPU* page boundary, or the page table in AMDGPU driver will be corrupted: > the value of num_entries must always be a multiple of > AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables. > You need to identify the root cause of this, most likely start or last > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE. IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable dev_info.gart_page_size" should be backported along with this, which makes the kernel to provide the CPU page size to libdrm and mesa and correct userspace behavior. I'm not sure why only one is backported. -- Xi Ruoyao <xry111@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2021-10-13 22:20 +0200 |
| Subject | Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? |
| Message-ID | <D7STf-1Mf-1@gated-at.bofh.it> |
| In reply to | #72279 |
Hi,
On Mon, Oct 11, 2021 at 10:30:21AM +0200, Christian König wrote:
> Am 10.10.21 um 16:14 schrieb Xi Ruoyao:
> > On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote:
> > > It occurs to me, quite belatedly, that it may be worth asking the
> > > author, reviewers, and signers of the change in question their
> > > thoughts on this bug report:
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D990279&data=04%7C01%7Cchristian.koenig%40amd.com%7C915628061dd746062c5408d98bf84df9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637694721282436279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V4R4BPCHNQzx2bF6STDzfjW%2BQezZg89w8%2FEeRpuRVnM%3D&reserved=0
> > >
> > > In particular, on ppc64 systems, Linux typically is configured to use
> > > a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page. It
> > > looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
> > > something (perhaps in userspace, even, eek?) is requesting
> > > 4KiB-but-not-64KiB alignment of this buffer.
> > Christian told me the buffer should be aligned to *CPU* page boundary,
> > or the page table in AMDGPU driver will be corrupted:
>
> Yeah, that's indeed correct. And that intentionally breaks because otherwise
> we can corrupt the page tables and potentially cause much worse trouble.
>
> Question is more why userspace isn't told the correct value in your branch.
>
> >
> > > the value of num_entries must always be a multiple of
> > > AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.
> > > You need to identify the root cause of this, most likely start or last
> > > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
> > IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> > dev_info.gart_page_size" should be backported along with this, which
> > makes the kernel to provide the CPU page size to libdrm and mesa and
> > correct userspace behavior. I'm not sure why only one is backported.
>
>
> Yes, exactly that sounds like the correct fix to me as well.
So, the 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo
map") was backported to several stable series 4.14.229, 4.19.185,
5.4.110, 5.10.28 and 5.11.12 but not the
f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
dev_info.gart_page_size".
What is confusely is that all of those backports reference as upstream
commit e3512fb67093fabdf27af303066627b921ee9bd8 and not
9a89a721b41b23c6da8f8a6dd0e382966a850dcf which might be in part source
of the confusion?
Can any of you request to backport
f4d3da72a76a9ce5f57bba64788931686a9dc333 as well for those stable
series where relevant?
Regards,
Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2021-10-30 16:40 +0200 |
| Subject | Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? |
| Message-ID | <DdXGx-3d5-1@gated-at.bofh.it> |
| In reply to | #73274 |
On Wed, Oct 13, 2021 at 10:08:21PM +0200, Salvatore Bonaccorso wrote:
> Hi,
>
> On Mon, Oct 11, 2021 at 10:30:21AM +0200, Christian König wrote:
> > Am 10.10.21 um 16:14 schrieb Xi Ruoyao:
> > > On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote:
> > > > It occurs to me, quite belatedly, that it may be worth asking the
> > > > author, reviewers, and signers of the change in question their
> > > > thoughts on this bug report:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D990279&data=04%7C01%7Cchristian.koenig%40amd.com%7C915628061dd746062c5408d98bf84df9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637694721282436279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V4R4BPCHNQzx2bF6STDzfjW%2BQezZg89w8%2FEeRpuRVnM%3D&reserved=0
> > > >
> > > > In particular, on ppc64 systems, Linux typically is configured to use
> > > > a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page. It
> > > > looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
> > > > something (perhaps in userspace, even, eek?) is requesting
> > > > 4KiB-but-not-64KiB alignment of this buffer.
> > > Christian told me the buffer should be aligned to *CPU* page boundary,
> > > or the page table in AMDGPU driver will be corrupted:
> >
> > Yeah, that's indeed correct. And that intentionally breaks because otherwise
> > we can corrupt the page tables and potentially cause much worse trouble.
> >
> > Question is more why userspace isn't told the correct value in your branch.
> >
> > >
> > > > the value of num_entries must always be a multiple of
> > > > AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.
> > > > You need to identify the root cause of this, most likely start or last
> > > > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
> > > IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> > > dev_info.gart_page_size" should be backported along with this, which
> > > makes the kernel to provide the CPU page size to libdrm and mesa and
> > > correct userspace behavior. I'm not sure why only one is backported.
> >
> >
> > Yes, exactly that sounds like the correct fix to me as well.
>
> So, the 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo
> map") was backported to several stable series 4.14.229, 4.19.185,
> 5.4.110, 5.10.28 and 5.11.12 but not the
> f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> dev_info.gart_page_size".
>
> What is confusely is that all of those backports reference as upstream
> commit e3512fb67093fabdf27af303066627b921ee9bd8 and not
> 9a89a721b41b23c6da8f8a6dd0e382966a850dcf which might be in part source
> of the confusion?
>
> Can any of you request to backport
> f4d3da72a76a9ce5f57bba64788931686a9dc333 as well for those stable
> series where relevant?
Here is the proposed change. Should this be submitted to stable for
5.10.y?
Regards,
Salvatore
From 02c987eb2ab0cdfd536d08bf812f4e37d3cc150a Mon Sep 17 00:00:00 2001
From: Huacai Chen <chenhc@lemote.com>
Date: Tue, 30 Mar 2021 23:33:33 +0800
Subject: [PATCH] drm/amdgpu: Set a suitable dev_info.gart_page_size
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit f4d3da72a76a9ce5f57bba64788931686a9dc333 upstream.
In Mesa, dev_info.gart_page_size is used for alignment and it was
set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU
driver requires an alignment on CPU pages. So, for non-4KB page system,
gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE).
Signed-off-by: Rui Wang <wangr@lemote.com>
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Link: https://github.com/loongson-community/linux-stable/commit/caa9c0a1
[Xi: rebased for drm-next, use max_t for checkpatch,
and reworded commit message.]
Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
Tested-by: Dan Horák <dan@danny.cz>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Salvatore Bonaccorso: Backport to 5.10.y which does not contain
a5a52a43eac0 ("drm/amd/amdgpu/amdgpu_kms: Remove 'struct
drm_amdgpu_info_device dev_info' from the stack") which removes dev_info
from the stack and places it on the heap.]
Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index efda38349a03..917b94002f4b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -766,9 +766,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
dev_info.high_va_offset = AMDGPU_GMC_HOLE_END;
dev_info.high_va_max = AMDGPU_GMC_HOLE_END | vm_size;
}
- dev_info.virtual_address_alignment = max((int)PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE);
+ dev_info.virtual_address_alignment = max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE);
dev_info.pte_fragment_size = (1 << adev->vm_manager.fragment_size) * AMDGPU_GPU_PAGE_SIZE;
- dev_info.gart_page_size = AMDGPU_GPU_PAGE_SIZE;
+ dev_info.gart_page_size = max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE);
dev_info.cu_active_number = adev->gfx.cu_info.number;
dev_info.cu_ao_mask = adev->gfx.cu_info.ao_cu_mask;
dev_info.ce_ram_size = adev->gfx.ce_ram_size;
--
2.33.0
[toc] | [prev] | [next] | [standalone]
| From | Nathaniel Filardo <nwfilardo@gmail.com> |
|---|---|
| Date | 2022-01-28 00:10 +0100 |
| Subject | Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? |
| Message-ID | <DKm3T-5xI-5@gated-at.bofh.it> |
| In reply to | #72279 |
It looks like the missing patch made its way into
5.15.0-0.bpo.2-powerpc64le, as f4d3da72a76a9ce... I think. As a
result, I think this bug is overcome by events and can be closed.
On Tue, Nov 2, 2021 at 12:37 PM Christian König
<christian.koenig@amd.com> wrote:
>
>
>
> Am 30.10.21 um 16:32 schrieb Salvatore Bonaccorso:
> > On Wed, Oct 13, 2021 at 10:08:21PM +0200, Salvatore Bonaccorso wrote:
> >> Hi,
> >>
> >> On Mon, Oct 11, 2021 at 10:30:21AM +0200, Christian König wrote:
> >>> Am 10.10.21 um 16:14 schrieb Xi Ruoyao:
> >>>> On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote:
> >>>>> It occurs to me, quite belatedly, that it may be worth asking the
> >>>>> author, reviewers, and signers of the change in question their
> >>>>> thoughts on this bug report:
> >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D990279&data=04%7C01%7Cchristian.koenig%40amd.com%7C3eab702e82bc4ab81fbd08d99bb21419%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637712012456263348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KFxF9He7545uxYylgQ%2F4HdljVuGoGUbvHh9xohbxu4o%3D&reserved=0
> >>>>>
> >>>>> In particular, on ppc64 systems, Linux typically is configured to use
> >>>>> a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page. It
> >>>>> looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
> >>>>> something (perhaps in userspace, even, eek?) is requesting
> >>>>> 4KiB-but-not-64KiB alignment of this buffer.
> >>>> Christian told me the buffer should be aligned to *CPU* page boundary,
> >>>> or the page table in AMDGPU driver will be corrupted:
> >>> Yeah, that's indeed correct. And that intentionally breaks because otherwise
> >>> we can corrupt the page tables and potentially cause much worse trouble.
> >>>
> >>> Question is more why userspace isn't told the correct value in your branch.
> >>>
> >>>>> the value of num_entries must always be a multiple of
> >>>>> AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.
> >>>>> You need to identify the root cause of this, most likely start or last
> >>>>> are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
> >>>> IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> >>>> dev_info.gart_page_size" should be backported along with this, which
> >>>> makes the kernel to provide the CPU page size to libdrm and mesa and
> >>>> correct userspace behavior. I'm not sure why only one is backported.
> >>>
> >>> Yes, exactly that sounds like the correct fix to me as well.
> >> So, the 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo
> >> map") was backported to several stable series 4.14.229, 4.19.185,
> >> 5.4.110, 5.10.28 and 5.11.12 but not the
> >> f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> >> dev_info.gart_page_size".
> >>
> >> What is confusely is that all of those backports reference as upstream
> >> commit e3512fb67093fabdf27af303066627b921ee9bd8 and not
> >> 9a89a721b41b23c6da8f8a6dd0e382966a850dcf which might be in part source
> >> of the confusion?
> >>
> >> Can any of you request to backport
> >> f4d3da72a76a9ce5f57bba64788931686a9dc333 as well for those stable
> >> series where relevant?
> > Here is the proposed change. Should this be submitted to stable for
> > 5.10.y?
>
> You can drop the max_t(), just using PAGE_SIZE should work since there
> can't be any smaller page size than 4k or the driver won't work at all.
>
> Regards,
> Christian.
>
> >
> > Regards,
> > Salvatore
> >
> > From 02c987eb2ab0cdfd536d08bf812f4e37d3cc150a Mon Sep 17 00:00:00 2001
> > From: Huacai Chen <chenhc@lemote.com>
> > Date: Tue, 30 Mar 2021 23:33:33 +0800
> > Subject: [PATCH] drm/amdgpu: Set a suitable dev_info.gart_page_size
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > commit f4d3da72a76a9ce5f57bba64788931686a9dc333 upstream.
> >
> > In Mesa, dev_info.gart_page_size is used for alignment and it was
> > set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU
> > driver requires an alignment on CPU pages. So, for non-4KB page system,
> > gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE).
> >
> > Signed-off-by: Rui Wang <wangr@lemote.com>
> > Signed-off-by: Huacai Chen <chenhc@lemote.com>
> > Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Floongson-community%2Flinux-stable%2Fcommit%2Fcaa9c0a1&data=04%7C01%7Cchristian.koenig%40amd.com%7C3eab702e82bc4ab81fbd08d99bb21419%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637712012456273340%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C8Dz22MXtb6u012FMN%2BRm0i9vDNkn5LJrkqX2qACzqY%3D&reserved=0
> > [Xi: rebased for drm-next, use max_t for checkpatch,
> > and reworded commit message.]
> > Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>
> > BugLink: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1549&data=04%7C01%7Cchristian.koenig%40amd.com%7C3eab702e82bc4ab81fbd08d99bb21419%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637712012456273340%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Azbz96fafUgilLJIFAOzXadKygHFVqYBxlh%2FYvhNtdE%3D&reserved=0
> > Tested-by: Dan Horák <dan@danny.cz>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> > [Salvatore Bonaccorso: Backport to 5.10.y which does not contain
> > a5a52a43eac0 ("drm/amd/amdgpu/amdgpu_kms: Remove 'struct
> > drm_amdgpu_info_device dev_info' from the stack") which removes dev_info
> > from the stack and places it on the heap.]
> > Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index efda38349a03..917b94002f4b 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -766,9 +766,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
> > dev_info.high_va_offset = AMDGPU_GMC_HOLE_END;
> > dev_info.high_va_max = AMDGPU_GMC_HOLE_END | vm_size;
> > }
> > - dev_info.virtual_address_alignment = max((int)PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE);
> > + dev_info.virtual_address_alignment = max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE);
> > dev_info.pte_fragment_size = (1 << adev->vm_manager.fragment_size) * AMDGPU_GPU_PAGE_SIZE;
> > - dev_info.gart_page_size = AMDGPU_GPU_PAGE_SIZE;
> > + dev_info.gart_page_size = max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE);
> > dev_info.cu_active_number = adev->gfx.cu_info.number;
> > dev_info.cu_ao_mask = adev->gfx.cu_info.ao_cu_mask;
> > dev_info.ce_ram_size = adev->gfx.ce_ram_size;
>
[toc] | [prev] | [next] | [standalone]
| From | Andrew <akaminski@mailfence.com> |
|---|---|
| Date | 2022-01-29 00:20 +0100 |
| Subject | Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines? |
| Message-ID | <DKIH7-2Gm-1@gated-at.bofh.it> |
| In reply to | #72279 |
[Multipart message — attachments visible in raw view] — view raw
As of kernel 5.15.5 (bpo) I see that max_t() is still used. If this is blocking any merge into the stable kernel patch, I can test it with just PAGE_SIZE to confirm whether it is okay. As it stands, I currently need to manually build the stable kernel in order to have a functioning Blackbird workstation. On Fri, 28 Jan 2022 00:16:27 +0100 Salvatore Bonaccorso <carnil@debian.org> wrote: > Source: linux > Source-Version: 5.13.9-1~exp1 > > Hi, > > On Thu, Jan 27, 2022 at 11:02:58PM +0000, Nathaniel Filardo wrote: > > It looks like the missing patch made its way into > > 5.15.0-0.bpo.2-powerpc64le, as f4d3da72a76a9ce... I think. As a > > result, I think this bug is overcome by events and can be closed. > > Indeed, thanks for reminding and referencing the upstream commit. > > Regards, > Salvatore > >
[toc] | [prev] | [next] | [standalone]
| From | Timothy Pearson <tpearson@raptorengineering.com> |
|---|---|
| Date | 2022-02-08 20:40 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DOEvf-sEL-13@gated-at.bofh.it> |
| In reply to | #72279 |
I can confirm Bullseye is still affected by this bug. Is there any chance of this fix being applied to the Bullseye stable kernels? We're having to maintain kernel builds in our own repositories to fix this regression, and that introduces some lag when e.g. security updates are pushed to Debian.
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2022-02-08 22:30 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DOGdH-tTL-1@gated-at.bofh.it> |
| In reply to | #74350 |
Hi Timothy, On Tue, Feb 08, 2022 at 01:23:10PM -0600, Timothy Pearson wrote: > I can confirm Bullseye is still affected by this bug. > > Is there any chance of this fix being applied to the Bullseye stable > kernels? We're having to maintain kernel builds in our own > repositories to fix this regression, and that introduces some lag > when e.g. security updates are pushed to Debian. This needs someone to submit a (tested) backport patch to stable maintainers, so it can be applied in the 5.10.y stable series. Christian, would it be possible to do that? Cf. https://bugs.debian.org/990279#42 and https://bugs.debian.org/990279#52 Regards, Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Timothy Pearson <tpearson@raptorengineering.com> |
|---|---|
| Date | 2022-02-08 22:30 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DOGdH-tTL-5@gated-at.bofh.it> |
| In reply to | #72279 |
----- Original Message ----- > From: "Salvatore Bonaccorso" <carnil@debian.org> > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "990279" <990279@bugs.debian.org> > Cc: "Christian König" <christian.koenig@amd.com>, "Xi Ruoyao" <xry111@mengyan1223.wang>, "Alex Deucher" > <alexander.deucher@amd.com> > Sent: Tuesday, February 8, 2022 3:16:32 PM > Subject: Re: Bug#990279: Status? > Hi Timothy, > > On Tue, Feb 08, 2022 at 01:23:10PM -0600, Timothy Pearson wrote: >> I can confirm Bullseye is still affected by this bug. >> >> Is there any chance of this fix being applied to the Bullseye stable >> kernels? We're having to maintain kernel builds in our own >> repositories to fix this regression, and that introduces some lag >> when e.g. security updates are pushed to Debian. > > This needs someone to submit a (tested) backport patch to > stable maintainers, so it can be applied in the 5.10.y stable series. I can confirm the patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279#47 is what we're using and that it does work as intended. If you need me to generate / submit a patch just let me know. > Christian, would it be possible to do that? Cf. > https://bugs.debian.org/990279#42 and > https://bugs.debian.org/990279#52 > > Regards, > Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Timothy Pearson <tpearson@raptorengineering.com> |
|---|---|
| Date | 2022-02-09 20:30 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DP0P7-GtC-1@gated-at.bofh.it> |
| In reply to | #72279 |
----- Original Message ----- > From: "Christian König" <christian.koenig@amd.com> > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "Salvatore Bonaccorso" <carnil@debian.org> >> >> If you need me to generate / submit a patch just let me know. > > Please do, I don't have time nor a test system to look into this. > > Regards, > Christian. Submitted here: https://lists.debian.org/debian-kernel/2022/02/msg00099.html
[toc] | [prev] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2022-02-09 21:30 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DP1Lb-H2K-3@gated-at.bofh.it> |
| In reply to | #74366 |
Hi Timothy, On Wed, Feb 09, 2022 at 01:20:40PM -0600, Timothy Pearson wrote: > ----- Original Message ----- > > From: "Christian König" <christian.koenig@amd.com> > > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "Salvatore Bonaccorso" <carnil@debian.org> > >> > >> If you need me to generate / submit a patch just let me know. > > > > Please do, I don't have time nor a test system to look into this. > > > > Regards, > > Christian. > > Submitted here: > https://lists.debian.org/debian-kernel/2022/02/msg00099.html This is not exactly what we meant. The idea is to submit it to upstream for stable 5.10.y so we can pick it up in Debian. I'm taking the backport in #47 now. It is now submitted here: https://lore.kernel.org/stable/20220209201624.1234062-1-carnil@debian.org/T/#u Regards, Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Timothy Pearson <tpearson@raptorengineering.com> |
|---|---|
| Date | 2022-02-09 21:30 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DP1Lb-H2K-7@gated-at.bofh.it> |
| In reply to | #74372 |
----- Original Message ----- > From: "Salvatore Bonaccorso" <carnil@debian.org> > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "990279" <990279@bugs.debian.org> > Cc: "Christian König" <christian.koenig@amd.com>, "Xi Ruoyao" <xry111@mengyan1223.wang>, "Alex Deucher" > <alexander.deucher@amd.com> > Sent: Wednesday, February 9, 2022 2:18:34 PM > Subject: Re: Bug#990279: Status? > Hi Timothy, > > On Wed, Feb 09, 2022 at 01:20:40PM -0600, Timothy Pearson wrote: >> ----- Original Message ----- >> > From: "Christian König" <christian.koenig@amd.com> >> > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "Salvatore Bonaccorso" >> > <carnil@debian.org> >> >> >> >> If you need me to generate / submit a patch just let me know. >> > >> > Please do, I don't have time nor a test system to look into this. >> > >> > Regards, >> > Christian. >> >> Submitted here: >> https://lists.debian.org/debian-kernel/2022/02/msg00099.html > > This is not exactly what we meant. The idea is to submit it to > upstream for stable 5.10.y so we can pick it up in Debian. I'm taking > the backport in #47 now. > > It is now submitted here: > https://lore.kernel.org/stable/20220209201624.1234062-1-carnil@debian.org/T/#u > > Regards, > Salvatore Understood, apologies for the mixup. I'll monitor the upstream submission and help push it through if needed. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Andrew <akaminski@mailfence.com> |
|---|---|
| Date | 2022-03-09 21:10 +0100 |
| Subject | Bug#990279: Status? |
| Message-ID | <DZaNb-EKl-11@gated-at.bofh.it> |
| In reply to | #72279 |
[Multipart message — attachments visible in raw view] — view raw
The patch appears to be applied as of kernel security update 5.10.0-12, linux_5.10.103-1 source. On Wed, 9 Feb 2022 14:22:23 -0600 (CST) Timothy Pearson <tpearson@raptorengineering.com> wrote: > > > ----- Original Message ----- > > From: "Salvatore Bonaccorso" <carnil@debian.org> > > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "990279" <990279@bugs.debian.org> > > Cc: "Christian König" <christian.koenig@amd.com>, "Xi Ruoyao" <xry111@mengyan1223.wang>, "Alex Deucher" > > <alexander.deucher@amd.com> > > Sent: Wednesday, February 9, 2022 2:18:34 PM > > Subject: Re: Bug#990279: Status? > > > Hi Timothy, > > > > On Wed, Feb 09, 2022 at 01:20:40PM -0600, Timothy Pearson wrote: > >> ----- Original Message ----- > >> > From: "Christian König" <christian.koenig@amd.com> > >> > To: "Timothy Pearson" <tpearson@raptorengineering.com>, "Salvatore Bonaccorso" > >> > <carnil@debian.org> > >> >> > >> >> If you need me to generate / submit a patch just let me know. > >> > > >> > Please do, I don't have time nor a test system to look into this. > >> > > >> > Regards, > >> > Christian. > >> > >> Submitted here: > >> <https://lists.debian.org/debian-kernel/2022/02/msg00099.html> > > > > This is not exactly what we meant. The idea is to submit it to > > upstream for stable 5.10.y so we can pick it up in Debian. I'm taking > > the backport in #47 now. > > > > It is now submitted here: > > <https://lore.kernel.org/stable/20220209201624.1234062-1-carnil@debian.org/T/#u> > > > > Regards, > > Salvatore > > Understood, apologies for the mixup. I'll monitor the upstream submission and help push it through if needed. > > Thanks! > >
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web