* stable-rc/queue/4.14 build: 196 builds: 3 failed, 193 passed, 2 errors, 32 warnings (v4.14.261)
From: kernelci.org bot @ 2022-01-05 20:52 UTC (permalink / raw)
To: stable, kernel-build-reports, kernelci-results
stable-rc/queue/4.14 build: 196 builds: 3 failed, 193 passed, 2 errors, 32 warnings (v4.14.261)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/queue%2F4.14/kernel/v4.14.261/
Tree: stable-rc
Branch: queue/4.14
Git Describe: v4.14.261
Git Commit: bfdef05c8da46b022172695aa493cff7ac667a4b
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 6 unique architectures
Build Failures Detected:
arm:
rpc_defconfig: (gcc-10) FAIL
mips:
ip27_defconfig: (gcc-10) FAIL
ip28_defconfig: (gcc-10) FAIL
Errors and Warnings Detected:
arc:
arm64:
arm:
mini2440_defconfig (gcc-10): 1 warning
omap1_defconfig (gcc-10): 1 warning
rpc_defconfig (gcc-10): 2 errors
s3c2410_defconfig (gcc-10): 1 warning
i386:
allnoconfig (gcc-10): 3 warnings
i386_defconfig (gcc-10): 3 warnings
tinyconfig (gcc-10): 3 warnings
mips:
malta_qemu_32r6_defconfig (gcc-10): 1 warning
mtx1_defconfig (gcc-10): 3 warnings
x86_64:
allnoconfig (gcc-10): 4 warnings
tinyconfig (gcc-10): 4 warnings
x86_64_defconfig (gcc-10): 4 warnings
x86_64_defconfig+x86-chromebook (gcc-10): 4 warnings
Errors summary:
1 arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
1 arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
Warnings summary:
7 ld: warning: creating DT_TEXTREL in a PIE
4 ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
4 arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
4 Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
3 ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
3 arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
2 sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
2 drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
1 {standard input}:30: Warning: macro instruction expanded into multiple instructions
1 sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
1 drivers/gpio/gpio-omap.c:1152:34: warning: array ‘omap_gpio_match’ assumed to have one element
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
allnoconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
at91_dt_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath79_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
badge4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_stb_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
db1xxx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ezx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gemini_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hsdk_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip22_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-10) — FAIL, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lasat_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
{standard input}:30: Warning: macro instruction expanded into multiple instructions
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_xpa_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations]
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap1_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/gpio/gpio-omap.c:1152:34: warning: array ‘omap_gpio_match’ assumed to have one element
--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omega2p_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pistachio_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-10) — FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv3
arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/tty/serial/samsung.c:1794:34: warning: array ‘s3c24xx_uart_dt_match’ assumed to have one element
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tango4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0219_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-10) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/entry/entry_32.S:482: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
ld: arch/x86/boot/compressed/head_32.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
tinyconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_smp_defconfig (arc, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vocore2_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
arch/x86/entry/entry_64.S:1642: Warning: no instruction mnemonic suffix given and no register operands; using default for `sysret'
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text'
ld: warning: creating DT_TEXTREL in a PIE
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
xilfpga_defconfig (mips, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [PATCH v2 5/7] target/ppc: Add MSR_ILE support to ppc_interrupts_little_endian
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
Some CPUs set ILE via an MSR bit. We can make
ppc_interrupts_little_endian handle that case as well. Now we have a
centralized way of determining the endianness of interrupts.
This change has no functional impact.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
target/ppc/cpu.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index a6fc857ad4..f99cd0ea92 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -2733,7 +2733,7 @@ static inline bool ppc_interrupts_little_endian(PowerPCCPU *cpu, bool hv)
{
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
CPUPPCState *env = &cpu->env;
- bool ile = false;
+ bool ile;
if (hv && env->has_hv_mode) {
if (is_isa300(pcc)) {
@@ -2744,6 +2744,8 @@ static inline bool ppc_interrupts_little_endian(PowerPCCPU *cpu, bool hv)
} else if (pcc->lpcr_mask & LPCR_ILE) {
ile = !!(env->spr[SPR_LPCR] & LPCR_ILE);
+ } else {
+ ile = !!(msr_ile);
}
return ile;
--
2.33.1
^ permalink raw reply related
* [PATCH v2 7/7] target/ppc: Introduce a wrapper for powerpc_excp
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
Next patches will split powerpc_excp in multiple family specific
handlers. This patch adds a wrapper to make the transition clearer.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
target/ppc/excp_helper.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index d16bdf9283..ea854a868e 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -397,7 +397,7 @@ static void powerpc_set_excp_state(PowerPCCPU *cpu,
* Note that this function should be greatly optimized when called
* with a constant excp, from ppc_hw_interrupt
*/
-static void powerpc_excp(PowerPCCPU *cpu, int excp)
+static inline void powerpc_excp_legacy(PowerPCCPU *cpu, int excp)
{
CPUState *cs = CPU(cpu);
CPUPPCState *env = &cpu->env;
@@ -868,6 +868,16 @@ static void powerpc_excp(PowerPCCPU *cpu, int excp)
powerpc_set_excp_state(cpu, vector, new_msr);
}
+static void powerpc_excp(PowerPCCPU *cpu, int excp)
+{
+ CPUPPCState *env = &cpu->env;
+
+ switch (env->excp_model) {
+ default:
+ powerpc_excp_legacy(cpu, excp);
+ }
+}
+
void ppc_cpu_do_interrupt(CPUState *cs)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
--
2.33.1
^ permalink raw reply related
* Re: [PATCH][V2] btrfs-progs: allow autodetect_object_types() to handle link.
From: Boris Burkov @ 2022-01-05 20:48 UTC (permalink / raw)
To: Goffredo Baroncelli; +Cc: linux-btrfs, Goffredo Baroncelli
In-Reply-To: <da4a4e0cf18df259e63c19872093bf12635da576.1641415488.git.kreijack@inwind.it>
On Wed, Jan 05, 2022 at 09:45:52PM +0100, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli <kreijack@inwind.it>
>
> The function autodetect_object_types() tries to detect the type of
> btrfs object passed. If it is an "inode" type (e.g. file) this function
> returns the type as "inode". If it is a block device, it return it as
> "block device".
> However it doesn't handle the case where the object passed is a link
> to a block device (which could be a valid btrfs device). For example
> LVM/DM creates link to block devices. In this case it should return
> the type as "block device".
>
> This patch replace the lstat() call with a stat().
>
> Reported-by: Boris Burkov <boris@bur.io>
Reviewed-by: Boris Burkov <boris@bur.io>
> Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
> ---
> cmds/property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmds/property.c b/cmds/property.c
> index 59ef997c..b3ccc0ff 100644
> --- a/cmds/property.c
> +++ b/cmds/property.c
> @@ -373,7 +373,7 @@ static int autodetect_object_types(const char *object, int *types_out)
>
> is_btrfs_object = check_btrfs_object(object);
>
> - ret = lstat(object, &st);
> + ret = stat(object, &st);
> if (ret < 0) {
> ret = -errno;
> goto out;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v6 1/9] mm: x86, arm64: add arch_has_hw_pte_young()
From: Yu Zhao @ 2022-01-05 20:47 UTC (permalink / raw)
To: Will Deacon
Cc: Andrew Morton, Linus Torvalds, Andi Kleen, Catalin Marinas,
Dave Hansen, Hillf Danton, Jens Axboe, Jesse Barnes,
Johannes Weiner, Jonathan Corbet, Matthew Wilcox, Mel Gorman,
Michael Larabel, Michal Hocko, Rik van Riel, Vlastimil Babka,
Ying Huang, linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
page-reclaim, x86, Konstantin Kharlamov
In-Reply-To: <20220105104526.GA3015@willie-the-truck>
On Wed, Jan 05, 2022 at 10:45:26AM +0000, Will Deacon wrote:
> On Tue, Jan 04, 2022 at 01:22:20PM -0700, Yu Zhao wrote:
> > Some architectures automatically set the accessed bit in PTEs, e.g.,
> > x86 and arm64 v8.2. On architectures that don't have this capability,
> > clearing the accessed bit in a PTE usually triggers a page fault
> > following the TLB miss of this PTE.
> >
> > Being aware of this capability can help make better decisions, e.g.,
> > whether to spread the work out over a period of time to avoid bursty
> > page faults when trying to clear the accessed bit in a large number of
> > PTEs.
> >
> > Signed-off-by: Yu Zhao <yuzhao@google.com>
> > Tested-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > ---
> > arch/arm64/include/asm/cpufeature.h | 5 +++++
> > arch/arm64/include/asm/pgtable.h | 13 ++++++++-----
> > arch/arm64/kernel/cpufeature.c | 19 +++++++++++++++++++
> > arch/arm64/tools/cpucaps | 1 +
> > arch/x86/include/asm/pgtable.h | 6 +++---
> > include/linux/pgtable.h | 13 +++++++++++++
> > mm/memory.c | 14 +-------------
> > 7 files changed, 50 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index ef6be92b1921..99518b4b2a9e 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -779,6 +779,11 @@ static inline bool system_supports_tlb_range(void)
> > cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
> > }
> >
> > +static inline bool system_has_hw_af(void)
> > +{
> > + return IS_ENABLED(CONFIG_ARM64_HW_AFDBM) && cpus_have_const_cap(ARM64_HW_AF);
> > +}
> > +
> > extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
> >
> > static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index c4ba047a82d2..e736f47436c7 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -999,13 +999,16 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
> > * page after fork() + CoW for pfn mappings. We don't always have a
> > * hardware-managed access flag on arm64.
> > */
> > -static inline bool arch_faults_on_old_pte(void)
> > +static inline bool arch_has_hw_pte_young(bool local)
> > {
> > - WARN_ON(preemptible());
> > + if (local) {
> > + WARN_ON(preemptible());
> > + return cpu_has_hw_af();
> > + }
> >
> > - return !cpu_has_hw_af();
> > + return system_has_hw_af();
> > }
> > -#define arch_faults_on_old_pte arch_faults_on_old_pte
> > +#define arch_has_hw_pte_young arch_has_hw_pte_young
> >
> > /*
> > * Experimentally, it's cheap to set the access flag in hardware and we
> > @@ -1013,7 +1016,7 @@ static inline bool arch_faults_on_old_pte(void)
> > */
> > static inline bool arch_wants_old_prefaulted_pte(void)
> > {
> > - return !arch_faults_on_old_pte();
> > + return arch_has_hw_pte_young(true);
> > }
> > #define arch_wants_old_prefaulted_pte arch_wants_old_prefaulted_pte
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 6f3e677d88f1..5bb553ee2c0e 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2171,6 +2171,25 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> > .matches = has_hw_dbm,
> > .cpu_enable = cpu_enable_hw_dbm,
> > },
> > + {
> > + /*
> > + * __cpu_setup always enables this capability. But if the boot
> > + * CPU has it and a late CPU doesn't, the absent
> > + * ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU will prevent this late CPU
> > + * from going online. There is neither known hardware does that
> > + * nor obvious reasons to design hardware works that way, hence
> > + * no point leaving the door open here. If the need arises, a
> > + * new weak system feature flag should do the trick.
> > + */
> > + .desc = "Hardware update of the Access flag",
> > + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + .capability = ARM64_HW_AF,
> > + .sys_reg = SYS_ID_AA64MMFR1_EL1,
> > + .sign = FTR_UNSIGNED,
> > + .field_pos = ID_AA64MMFR1_HADBS_SHIFT,
> > + .min_field_value = 1,
> > + .matches = has_cpuid_feature,
> > + },
> > #endif
> > {
> > .desc = "CRC32 instructions",
> > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > index 870c39537dd0..56e4ef5d95fa 100644
> > --- a/arch/arm64/tools/cpucaps
> > +++ b/arch/arm64/tools/cpucaps
> > @@ -36,6 +36,7 @@ HAS_STAGE2_FWB
> > HAS_SYSREG_GIC_CPUIF
> > HAS_TLB_RANGE
> > HAS_VIRT_HOST_EXTN
> > +HW_AF
> > HW_DBM
> > KVM_PROTECTED_MODE
> > MISMATCHED_CACHE_TYPE
>
> As discussed in the previous threads, we really don't need the complexity
> of the additional cap for the arm64 part. Please can you just use the
> existing code instead? It's both simpler and, as you say, it's equivalent
> for existing hardware.
>
> That way, this patch just ends up being a renaming exercise and we're all
> good.
No, renaming alone isn't enough. A caller needs to disable preemption
before calling system_has_hw_af(), and I don't think it's reasonable
to ask this caller to do it on x86 as well.
It seems you really prefer not to have HW_AF. So the best I can
accommodate, considering other potential archs, e.g., risc-v (I do
plan to provide benchmark results on risc-v, btw), is:
static inline bool arch_has_hw_pte_young(bool local)
{
bool hw_af;
if (local) {
WARN_ON(preemptible());
return cpu_has_hw_af();
}
preempt_disable();
hw_af = system_has_hw_af();
preempt_enable();
return hw_af;
}
Or please give me something else I can call without disabling
preemption, sounds good?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ALSA: seq: virmidi: Add a drain operation
From: Stefan Sauer @ 2022-01-05 20:47 UTC (permalink / raw)
To: alsa-devel; +Cc: Stefan Sauer
In-Reply-To: <CAJ4JBRO7qE63TAC-=4y=QMaiAEfkyjRmgiZEF_57Hm+ztc8+Qg@mail.gmail.com>
If a driver does not supply a drain operation for outputs, a default code
path will execute msleep(50). Especially for a virtual midi device
this severely limmits the throughput.
This implementation for the virtual midi driver simply flushes the output
workqueue.
Signed-off-by: Stefan Sauer <st.kost@gmail.com>
---
sound/core/seq/seq_virmidi.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/sound/core/seq/seq_virmidi.c b/sound/core/seq/seq_virmidi.c
index 4abc38c70cae..f5cae49500c8 100644
--- a/sound/core/seq/seq_virmidi.c
+++ b/sound/core/seq/seq_virmidi.c
@@ -262,6 +262,16 @@ static int snd_virmidi_output_close(struct snd_rawmidi_substream *substream)
return 0;
}
+/*
+ * drain output work queue
+ */
+static void snd_virmidi_output_drain(struct snd_rawmidi_substream *substream)
+{
+ struct snd_virmidi *vmidi = substream->runtime->private_data;
+
+ flush_work(&vmidi->output_work);
+}
+
/*
* subscribe callback - allow output to rawmidi device
*/
@@ -336,6 +346,7 @@ static const struct snd_rawmidi_ops snd_virmidi_output_ops = {
.open = snd_virmidi_output_open,
.close = snd_virmidi_output_close,
.trigger = snd_virmidi_output_trigger,
+ .drain = snd_virmidi_output_drain,
};
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/7] target/ppc: Use ppc_interrupts_little_endian in powerpc_excp
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
The ppc_interrupts_little_endian function is now suitable for
determining the endianness of interrupts for all CPUs.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
target/ppc/excp_helper.c | 29 +----------------------------
1 file changed, 1 insertion(+), 28 deletions(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 92953af896..d16bdf9283 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -833,36 +833,9 @@ static void powerpc_excp(PowerPCCPU *cpu, int excp)
* Sort out endianness of interrupt, this differs depending on the
* CPU, the HV mode, etc...
*/
-#ifdef TARGET_PPC64
- if (excp_model == POWERPC_EXCP_POWER7) {
- if (!(new_msr & MSR_HVB) && (env->spr[SPR_LPCR] & LPCR_ILE)) {
- new_msr |= (target_ulong)1 << MSR_LE;
- }
- } else if (excp_model == POWERPC_EXCP_POWER8) {
- if (new_msr & MSR_HVB) {
- if (env->spr[SPR_HID0] & HID0_HILE) {
- new_msr |= (target_ulong)1 << MSR_LE;
- }
- } else if (env->spr[SPR_LPCR] & LPCR_ILE) {
- new_msr |= (target_ulong)1 << MSR_LE;
- }
- } else if (excp_model == POWERPC_EXCP_POWER9 ||
- excp_model == POWERPC_EXCP_POWER10) {
- if (new_msr & MSR_HVB) {
- if (env->spr[SPR_HID0] & HID0_POWER9_HILE) {
- new_msr |= (target_ulong)1 << MSR_LE;
- }
- } else if (env->spr[SPR_LPCR] & LPCR_ILE) {
- new_msr |= (target_ulong)1 << MSR_LE;
- }
- } else if (msr_ile) {
+ if (ppc_interrupts_little_endian(cpu, !!(new_msr & MSR_HVB))) {
new_msr |= (target_ulong)1 << MSR_LE;
}
-#else
- if (msr_ile) {
- new_msr |= (target_ulong)1 << MSR_LE;
- }
-#endif
#if defined(TARGET_PPC64)
if (excp_model == POWERPC_EXCP_BOOKE) {
--
2.33.1
^ permalink raw reply related
* Re: [PATCH rdma-next] IB/mlx5: Expose NDR speed through MAD
From: Jason Gunthorpe @ 2022-01-05 20:47 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Maher Sanalla, linux-kernel, linux-rdma, Michael Guralnik
In-Reply-To: <a2ab630d2a634547db9b581faa9d65da2edb9d05.1639554831.git.leonro@nvidia.com>
On Wed, Dec 15, 2021 at 09:54:31AM +0200, Leon Romanovsky wrote:
> From: Maher Sanalla <msanalla@nvidia.com>
>
> Under MAD query port, Report NDR speed when NDR is supported
> in the port capability mask.
>
> Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/infiniband/hw/mlx5/mad.c | 5 +++++
> include/rdma/ib_mad.h | 1 +
> 2 files changed, 6 insertions(+)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH 2/2] udoo: neo: Do not print the Model information
From: Tommaso Merciai @ 2022-01-05 20:47 UTC (permalink / raw)
To: Fabio Estevam; +Cc: sbabic, u-boot, pbrobinson
In-Reply-To: <20220103151512.435434-2-festevam@gmail.com>
On Mon, Jan 03, 2022 at 12:15:12PM -0300, Fabio Estevam wrote:
> By default the Model information from DT is printed:
>
> CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> CPU: Extended Commercial temperature grade (-20C to 105C) at 63C
> Reset cause: POR
> Model: UDOO Neo Basic
> Board: UDOO Neo FULL
> I2C: ready
>
> As the udoo basic DT is used, such output may be confusing.
>
> Improve it by only printing the Board model instead, which is
> read from the board identification GPIOs.
Hi Fabio,
Thanks, I test your patch on basic and extended model. Below some logs
seems all work properly. I hope I helped the cause :)
- BASIC log:
-------------------------------------------------------------------------
U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 32C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo BASIC
I2C: ready
DRAM: 512 MiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2188000 [PRIME]
Hit
--------------------------------------------------------------------------
- EXTENDED LOG:
--------------------------------------------------------------------------
U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 42C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo EXTENDED
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net:
Error: ethernet@2188000 address not set.
No ethernet found.
Hit any key to stop autoboot: 0
----------------------------------------------------------------------------
Acked-by: Tommaso Merciai <tomm.merciai@gmail.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
Tommaso
>
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
> This applies on top of Peter's series:
> https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T
>
> board/udoo/neo/neo.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
> index 0c0d3f615d18..da6a0b4e9247 100644
> --- a/board/udoo/neo/neo.c
> +++ b/board/udoo/neo/neo.c
> @@ -350,7 +350,8 @@ static char *board_string(int type)
> return "UNDEFINED";
> }
>
> -int checkboard(void)
> +/* Override the default implementation, DT model is not accurate */
> +int show_board_info(void)
> {
> int *board_type = (int *)OCRAM_START;
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 1/2] sched/core: Cookied forceidle accounting per cpu
From: Josh Don @ 2022-01-05 20:47 UTC (permalink / raw)
To: cruzzhao
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Benjamin Segall, Mel Gorman,
Daniel Bristot de Oliveira, Alexey Dobriyan, Eric Dumazet,
linux-kernel, linux-fsdevel
In-Reply-To: <b02204ea-0683-2879-5843-4cfb31d44d27@linux.alibaba.com>
On Wed, Jan 5, 2022 at 3:33 AM cruzzhao <cruzzhao@linux.alibaba.com> wrote:
>
> Firstly, attributing forced idle time to the specific cpus it happens on
> can help us measure the effect of steal_cookie_task(). We found out that
> steal_cookie_task() conflicts with load balance sometimes, for example,
> a cookie'd task is stolen by steal_cookie_task(), but it'll be migrated
> to another core by load balance soon.
I don't see how this is very helpful for steal_cookie_task(), since it
isn't a targeted metric for that specific case. If you were interested
in that specifically, I'd think you'd want to look at more direct
metrics, such as task migration counts, or adding some
accounting/histogram for the time between steal and load balance away.
> Secondly, a more convenient way of
> summing forced idle instead of iterating cookie'd task is indeed what we
> need. In the multi-rent scenario, it'll be complex to maintain the list
> of cookie'd task and it'll cost a lot to iterate it.
That motivation makes more sense to me. Have you considered
accumulating this at the cgroup level (ie. attributing it as another
type of usage)?
^ permalink raw reply
* Re: [PATCH v6 1/9] mm: x86, arm64: add arch_has_hw_pte_young()
From: Yu Zhao @ 2022-01-05 20:47 UTC (permalink / raw)
To: Will Deacon
Cc: Andrew Morton, Linus Torvalds, Andi Kleen, Catalin Marinas,
Dave Hansen, Hillf Danton, Jens Axboe, Jesse Barnes,
Johannes Weiner, Jonathan Corbet, Matthew Wilcox, Mel Gorman,
Michael Larabel, Michal Hocko, Rik van Riel, Vlastimil Babka,
Ying Huang, linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
page-reclaim, x86, Konstantin Kharlamov
In-Reply-To: <20220105104526.GA3015@willie-the-truck>
On Wed, Jan 05, 2022 at 10:45:26AM +0000, Will Deacon wrote:
> On Tue, Jan 04, 2022 at 01:22:20PM -0700, Yu Zhao wrote:
> > Some architectures automatically set the accessed bit in PTEs, e.g.,
> > x86 and arm64 v8.2. On architectures that don't have this capability,
> > clearing the accessed bit in a PTE usually triggers a page fault
> > following the TLB miss of this PTE.
> >
> > Being aware of this capability can help make better decisions, e.g.,
> > whether to spread the work out over a period of time to avoid bursty
> > page faults when trying to clear the accessed bit in a large number of
> > PTEs.
> >
> > Signed-off-by: Yu Zhao <yuzhao@google.com>
> > Tested-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > ---
> > arch/arm64/include/asm/cpufeature.h | 5 +++++
> > arch/arm64/include/asm/pgtable.h | 13 ++++++++-----
> > arch/arm64/kernel/cpufeature.c | 19 +++++++++++++++++++
> > arch/arm64/tools/cpucaps | 1 +
> > arch/x86/include/asm/pgtable.h | 6 +++---
> > include/linux/pgtable.h | 13 +++++++++++++
> > mm/memory.c | 14 +-------------
> > 7 files changed, 50 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index ef6be92b1921..99518b4b2a9e 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -779,6 +779,11 @@ static inline bool system_supports_tlb_range(void)
> > cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
> > }
> >
> > +static inline bool system_has_hw_af(void)
> > +{
> > + return IS_ENABLED(CONFIG_ARM64_HW_AFDBM) && cpus_have_const_cap(ARM64_HW_AF);
> > +}
> > +
> > extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
> >
> > static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index c4ba047a82d2..e736f47436c7 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -999,13 +999,16 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
> > * page after fork() + CoW for pfn mappings. We don't always have a
> > * hardware-managed access flag on arm64.
> > */
> > -static inline bool arch_faults_on_old_pte(void)
> > +static inline bool arch_has_hw_pte_young(bool local)
> > {
> > - WARN_ON(preemptible());
> > + if (local) {
> > + WARN_ON(preemptible());
> > + return cpu_has_hw_af();
> > + }
> >
> > - return !cpu_has_hw_af();
> > + return system_has_hw_af();
> > }
> > -#define arch_faults_on_old_pte arch_faults_on_old_pte
> > +#define arch_has_hw_pte_young arch_has_hw_pte_young
> >
> > /*
> > * Experimentally, it's cheap to set the access flag in hardware and we
> > @@ -1013,7 +1016,7 @@ static inline bool arch_faults_on_old_pte(void)
> > */
> > static inline bool arch_wants_old_prefaulted_pte(void)
> > {
> > - return !arch_faults_on_old_pte();
> > + return arch_has_hw_pte_young(true);
> > }
> > #define arch_wants_old_prefaulted_pte arch_wants_old_prefaulted_pte
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 6f3e677d88f1..5bb553ee2c0e 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2171,6 +2171,25 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> > .matches = has_hw_dbm,
> > .cpu_enable = cpu_enable_hw_dbm,
> > },
> > + {
> > + /*
> > + * __cpu_setup always enables this capability. But if the boot
> > + * CPU has it and a late CPU doesn't, the absent
> > + * ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU will prevent this late CPU
> > + * from going online. There is neither known hardware does that
> > + * nor obvious reasons to design hardware works that way, hence
> > + * no point leaving the door open here. If the need arises, a
> > + * new weak system feature flag should do the trick.
> > + */
> > + .desc = "Hardware update of the Access flag",
> > + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + .capability = ARM64_HW_AF,
> > + .sys_reg = SYS_ID_AA64MMFR1_EL1,
> > + .sign = FTR_UNSIGNED,
> > + .field_pos = ID_AA64MMFR1_HADBS_SHIFT,
> > + .min_field_value = 1,
> > + .matches = has_cpuid_feature,
> > + },
> > #endif
> > {
> > .desc = "CRC32 instructions",
> > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > index 870c39537dd0..56e4ef5d95fa 100644
> > --- a/arch/arm64/tools/cpucaps
> > +++ b/arch/arm64/tools/cpucaps
> > @@ -36,6 +36,7 @@ HAS_STAGE2_FWB
> > HAS_SYSREG_GIC_CPUIF
> > HAS_TLB_RANGE
> > HAS_VIRT_HOST_EXTN
> > +HW_AF
> > HW_DBM
> > KVM_PROTECTED_MODE
> > MISMATCHED_CACHE_TYPE
>
> As discussed in the previous threads, we really don't need the complexity
> of the additional cap for the arm64 part. Please can you just use the
> existing code instead? It's both simpler and, as you say, it's equivalent
> for existing hardware.
>
> That way, this patch just ends up being a renaming exercise and we're all
> good.
No, renaming alone isn't enough. A caller needs to disable preemption
before calling system_has_hw_af(), and I don't think it's reasonable
to ask this caller to do it on x86 as well.
It seems you really prefer not to have HW_AF. So the best I can
accommodate, considering other potential archs, e.g., risc-v (I do
plan to provide benchmark results on risc-v, btw), is:
static inline bool arch_has_hw_pte_young(bool local)
{
bool hw_af;
if (local) {
WARN_ON(preemptible());
return cpu_has_hw_af();
}
preempt_disable();
hw_af = system_has_hw_af();
preempt_enable();
return hw_af;
}
Or please give me something else I can call without disabling
preemption, sounds good?
^ permalink raw reply
* Re: [PATCH 02/10] exit: Add and use make_task_dead.
From: Eric W. Biederman @ 2022-01-05 20:46 UTC (permalink / raw)
To: Al Viro
Cc: linux-kernel, linux-arch, Linus Torvalds, Alexey Gladkov,
Kyle Huey, Oleg Nesterov, Kees Cook, Heiko Carstens,
Vasily Gorbik, Christian Borntraeger, Alexander Gordeev,
Martin Schwidefsky, Chris Zankel, Max Filippov
In-Reply-To: <YdUmN7n4W5YETUhW@zeniv-ca.linux.org.uk>
Al Viro <viro@zeniv.linux.org.uk> writes:
> On Wed, Dec 08, 2021 at 02:25:24PM -0600, Eric W. Biederman wrote:
>> There are two big uses of do_exit. The first is it's design use to be
>> the guts of the exit(2) system call. The second use is to terminate
>> a task after something catastrophic has happened like a NULL pointer
>> in kernel code.
>>
>> Add a function make_task_dead that is initialy exactly the same as
>> do_exit to cover the cases where do_exit is called to handle
>> catastrophic failure. In time this can probably be reduced to just a
>> light wrapper around do_task_dead. For now keep it exactly the same so
>> that there will be no behavioral differences introducing this new
>> concept.
>>
>> Replace all of the uses of do_exit that use it for catastraphic
>> task cleanup with make_task_dead to make it clear what the code
>> is doing.
>>
>> As part of this rename rewind_stack_do_exit
>> rewind_stack_and_make_dead.
>
> Umm... What about .Linvalid_mask: in arch/xtensa/kernel/entry.S?
> That's an obvious case for your make_task_dead().
Good catch.
Being in assembly it did not have anything after the name do_exit so it
hid from my regex "[^A-Za-z0-9_]do_exit[^A-Za-z0-9]". Thank you for
finding that.
Skimming the surrounding code it looks like Linvalid_mask can only be
reached by buggy hardware or buggy kernel code. If userspace could
trigger the condition it would be a candidate for force_exit_sig.
I am a bit puzzled why die is not called, instead of die being
handrolled there.
xtensa folks any thoughts?
If not I will queue up a minimal patch to replace do_exit with
make_task_dead.
Eric
^ permalink raw reply
* [PATCH][V2] btrfs-progs: allow autodetect_object_types() to handle link.
From: Goffredo Baroncelli @ 2022-01-05 20:45 UTC (permalink / raw)
To: linux-btrfs; +Cc: Boris Burkov, Goffredo Baroncelli
From: Goffredo Baroncelli <kreijack@inwind.it>
The function autodetect_object_types() tries to detect the type of
btrfs object passed. If it is an "inode" type (e.g. file) this function
returns the type as "inode". If it is a block device, it return it as
"block device".
However it doesn't handle the case where the object passed is a link
to a block device (which could be a valid btrfs device). For example
LVM/DM creates link to block devices. In this case it should return
the type as "block device".
This patch replace the lstat() call with a stat().
Reported-by: Boris Burkov <boris@bur.io>
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
---
cmds/property.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmds/property.c b/cmds/property.c
index 59ef997c..b3ccc0ff 100644
--- a/cmds/property.c
+++ b/cmds/property.c
@@ -373,7 +373,7 @@ static int autodetect_object_types(const char *object, int *types_out)
is_btrfs_object = check_btrfs_object(object);
- ret = lstat(object, &st);
+ ret = stat(object, &st);
if (ret < 0) {
ret = -errno;
goto out;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] target/ppc: powerpc_excp: Keep 60x soft MMU logs active
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
Remove the compile time definition and make the logging be controlled
by the `-d mmu` option in the cmdline.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
target/ppc/excp_helper.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 2c5d5470de..ce86b2ae37 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -30,8 +30,6 @@
#include "exec/cpu_ldst.h"
#endif
-/* #define DEBUG_SOFTWARE_TLB */
-
/*****************************************************************************/
/* Exception processing */
#if !defined(CONFIG_USER_ONLY)
@@ -137,7 +135,6 @@ static void dump_hcall(CPUPPCState *env)
static void ppc_excp_debug_sw_tlb(CPUPPCState *env, int excp)
{
-#if defined(DEBUG_SOFTWARE_TLB)
const char *es;
target_ulong *miss, *cmp;
int en;
@@ -161,12 +158,12 @@ static void ppc_excp_debug_sw_tlb(CPUPPCState *env, int excp)
miss = &env->spr[SPR_DMISS];
cmp = &env->spr[SPR_DCMP];
}
- qemu_log("6xx %sTLB miss: %cM " TARGET_FMT_lx " %cC "
- TARGET_FMT_lx " H1 " TARGET_FMT_lx " H2 "
- TARGET_FMT_lx " %08x\n", es, en, *miss, en, *cmp,
- env->spr[SPR_HASH1], env->spr[SPR_HASH2],
- env->error_code);
-#endif
+
+ qemu_log_mask(CPU_LOG_MMU, "6xx %sTLB miss: %cM " TARGET_FMT_lx " %cC "
+ TARGET_FMT_lx " H1 " TARGET_FMT_lx " H2 "
+ TARGET_FMT_lx " %08x\n", es, en, *miss, en, *cmp,
+ env->spr[SPR_HASH1], env->spr[SPR_HASH2],
+ env->error_code);
}
--
2.33.1
^ permalink raw reply related
* [GIT PULL] Networking for 5.16-final
From: Jakub Kicinski @ 2022-01-05 20:45 UTC (permalink / raw)
To: torvalds; +Cc: kuba, davem, netdev, linux-kernel
Hi Linus!
One last PR, turns out some of the recent fixes did more harm than good.
The following changes since commit 74c78b4291b4466b44a57b3b7c3b98ad02628686:
Merge tag 'net-5.16-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2021-12-30 11:12:12 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-5.16-final
for you to fetch changes up to db54c12a3d7e3eedd37aa08efc9362e905f07716:
selftests: set amt.sh executable (2022-01-05 10:27:19 -0800)
----------------------------------------------------------------
Networking fixes for 5.16-final, including fixes from bpf, and WiFi.
Current release - regressions:
- Revert "xsk: Do not sleep in poll() when need_wakeup set",
made the problem worse
- Revert "net: phy: fixed_phy: Fix NULL vs IS_ERR() checking in
__fixed_phy_register", broke EPROBE_DEFER handling
- Revert "net: usb: r8152: Add MAC pass-through support for more
Lenovo Docks", broke setups without a Lenovo dock
Current release - new code bugs:
- selftests: set amt.sh executable
Previous releases - regressions:
- batman-adv: mcast: don't send link-local multicast to mcast routers
Previous releases - always broken:
- ipv4/ipv6: check attribute length for RTA_FLOW / RTA_GATEWAY
- sctp: hold endpoint before calling cb in
sctp_transport_lookup_process
- mac80211: mesh: embed mesh_paths and mpp_paths into
ieee80211_if_mesh to avoid complicated handling of sub-object
allocation failures
- seg6: fix traceroute in the presence of SRv6
- tipc: fix a kernel-infoleak in __tipc_sendmsg()
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
----------------------------------------------------------------
Aaron Ma (1):
Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
Andrew Lunn (3):
seg6: export get_srh() for ICMP handling
icmp: ICMPV6: Examine invoking packet for Segment Route Headers.
udp6: Use Segment Routing Header for dest address if present
Arthur Kiyanovski (3):
net: ena: Fix undefined state when tx request id is out of bounds
net: ena: Fix wrong rx request id by resetting device
net: ena: Fix error handling when calculating max IO queues number
Christoph Hellwig (1):
netrom: fix copying in user data in nr_setsockopt
Colin Ian King (1):
bpf, selftests: Fix spelling mistake "tained" -> "tainted"
David Ahern (7):
ipv4: Check attribute length for RTA_GATEWAY in multipath route
ipv4: Check attribute length for RTA_FLOW in multipath route
ipv6: Check attribute length for RTA_GATEWAY in multipath route
ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route
lwtunnel: Validate RTA_ENCAP_TYPE attribute length
ipv6: Continue processing multipath route even if gateway attribute is invalid
ipv6: Do cleanup if attribute validation fails in multipath route
David S. Miller (4):
Merge branch 'mpr-len-checks' David Ahern says:
Merge branch 'ena-fixes'
Merge branch 'srv6-traceroute'
Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Di Zhu (1):
i40e: fix use-after-free in i40e_sync_filters_subtask()
Eric Dumazet (1):
sch_qfq: prevent shift-out-of-bounds in qfq_init_qdisc
Florian Fainelli (1):
Revert "net: phy: fixed_phy: Fix NULL vs IS_ERR() checking in __fixed_phy_register"
Gagan Kumar (1):
mctp: Remove only static neighbour on RTM_DELNEIGH
Haimin Zhang (1):
net ticp:fix a kernel-infoleak in __tipc_sendmsg()
Jakub Kicinski (4):
Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Merge tag 'batadv-net-pullrequest-20220103' of git://git.open-mesh.org/linux-merge
Merge tag 'mac80211-for-net-2022-01-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Merge tag 'ieee802154-for-net-2022-01-05' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
Jedrzej Jagielski (1):
i40e: Fix incorrect netdev's real number of RX/TX queues
Jianguo Wu (1):
selftests: net: udpgro_fwd.sh: explicitly checking the available ping feature
Karen Sornek (1):
iavf: Fix limit of total number of queues to active queues of VF
Linus Lüssing (1):
batman-adv: mcast: don't send link-local multicast to mcast routers
Magnus Karlsson (1):
Revert "xsk: Do not sleep in poll() when need_wakeup set"
Markus Koch (1):
net/fsl: Remove leftover definition in xgmac_mdio
Martin Habets (1):
sfc: The RX page_ring is optional
Mateusz Palczewski (2):
i40e: Fix to not show opcode msg on unsuccessful VF MAC change
i40e: Fix for displaying message regarding NVM version
Pavel Skripkin (2):
mac80211: mesh: embedd mesh_paths and mpp_paths into ieee80211_if_mesh
ieee802154: atusb: fix uninit value in atusb_set_extended_addr
Taehee Yoo (1):
selftests: set amt.sh executable
Thomas Toye (1):
rndis_host: support Hytera digital radios
Tom Rix (1):
mac80211: initialize variable have_higher_than_11mbit
Xin Long (1):
sctp: hold endpoint before calling cb in sctp_transport_lookup_process
drivers/net/ethernet/amazon/ena/ena_netdev.c | 49 +++++++-----
drivers/net/ethernet/freescale/xgmac_mdio.c | 1 -
drivers/net/ethernet/intel/i40e/i40e_main.c | 60 ++++++++++++---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 40 ++++++++--
drivers/net/ethernet/intel/iavf/iavf_main.c | 5 +-
drivers/net/ethernet/sfc/falcon/rx.c | 5 ++
drivers/net/ethernet/sfc/rx_common.c | 5 ++
drivers/net/ieee802154/atusb.c | 10 ++-
drivers/net/phy/fixed_phy.c | 4 +-
drivers/net/usb/r8152.c | 9 ++-
drivers/net/usb/rndis_host.c | 5 ++
include/linux/ipv6.h | 2 +
include/net/sctp/sctp.h | 3 +-
include/net/seg6.h | 21 +++++
net/batman-adv/multicast.c | 15 ++--
net/batman-adv/multicast.h | 10 ++-
net/batman-adv/soft-interface.c | 7 +-
net/core/lwtunnel.c | 4 +
net/ipv4/fib_semantics.c | 49 ++++++++++--
net/ipv6/icmp.c | 6 +-
net/ipv6/route.c | 32 +++++++-
net/ipv6/seg6.c | 59 ++++++++++++++
net/ipv6/seg6_local.c | 33 +-------
net/ipv6/udp.c | 3 +-
net/mac80211/ieee80211_i.h | 24 +++++-
net/mac80211/mesh.h | 22 +-----
net/mac80211/mesh_pathtbl.c | 89 ++++++++--------------
net/mac80211/mlme.c | 2 +-
net/mctp/neigh.c | 9 ++-
net/netrom/af_netrom.c | 2 +-
net/sched/sch_qfq.c | 6 +-
net/sctp/diag.c | 46 +++++------
net/sctp/socket.c | 22 ++++--
net/tipc/socket.c | 2 +
net/xdp/xsk.c | 4 +-
.../selftests/bpf/verifier/value_ptr_arith.c | 2 +-
tools/testing/selftests/net/amt.sh | 0
tools/testing/selftests/net/udpgro_fwd.sh | 3 +-
38 files changed, 441 insertions(+), 229 deletions(-)
mode change 100644 => 100755 tools/testing/selftests/net/amt.sh
^ permalink raw reply
* Re: [PATCH] iomap: Address soft lockup in iomap_finish_ioend()
From: Trond Myklebust @ 2022-01-05 20:45 UTC (permalink / raw)
To: david@fromorbit.com
Cc: bfoster@redhat.com, linux-fsdevel@vger.kernel.org,
trondmy@kernel.org, hch@infradead.org, axboe@kernel.dk,
djwong@kernel.org, linux-xfs@vger.kernel.org, willy@infradead.org
In-Reply-To: <0996c40657b5873dda5119344bf74556491e27b9.camel@hammerspace.com>
On Tue, 2022-01-04 at 21:09 -0500, Trond Myklebust wrote:
> On Tue, 2022-01-04 at 12:22 +1100, Dave Chinner wrote:
> > On Tue, Jan 04, 2022 at 12:04:23AM +0000, Trond Myklebust wrote:
> > > On Tue, 2022-01-04 at 09:03 +1100, Dave Chinner wrote:
> > > > On Sat, Jan 01, 2022 at 05:39:45PM +0000, Trond Myklebust
> > > > wrote:
> > > > > On Sat, 2022-01-01 at 14:55 +1100, Dave Chinner wrote:
> > > > > > As it is, if you are getting soft lockups in this location,
> > > > > > that's
> > > > > > an indication that the ioend chain that is being built by
> > > > > > XFS
> > > > > > is
> > > > > > way, way too long. IOWs, the completion latency problem is
> > > > > > caused
> > > > > > by
> > > > > > a lack of submit side ioend chain length bounding in
> > > > > > combination
> > > > > > with unbound completion side merging in xfs_end_bio - it's
> > > > > > not a
> > > > > > problem with the generic iomap code....
> > > > > >
> > > > > > Let's try to address this in the XFS code, rather than hack
> > > > > > unnecessary band-aids over the problem in the generic
> > > > > > code...
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Dave.
> > > > >
> > > > > Fair enough. As long as someone is working on a solution,
> > > > > then
> > > > > I'm
> > > > > happy. Just a couple of things:
> > > > >
> > > > > Firstly, we've verified that the cond_resched() in the bio
> > > > > loop
> > > > > does
> > > > > suffice to resolve the issue with XFS, which would tend to
> > > > > confirm
> > > > > what
> > > > > you're saying above about the underlying issue being the
> > > > > ioend
> > > > > chain
> > > > > length.
> > > > >
> > > > > Secondly, note that we've tested this issue with a variety of
> > > > > older
> > > > > kernels, including 4.18.x, 5.1.x and 5.15.x, so please bear
> > > > > in
> > > > > mind
> > > > > that it would be useful for any fix to be backward portable
> > > > > through
> > > > > the
> > > > > stable mechanism.
> > > >
> > > > The infrastructure hasn't changed that much, so whatever the
> > > > result
> > > > is it should be backportable.
> > > >
> > > > As it is, is there a specific workload that triggers this
> > > > issue?
> > > > Or
> > > > a specific machine config (e.g. large memory, slow storage).
> > > > Are
> > > > there large fragmented files in use (e.g. randomly written VM
> > > > image
> > > > files)? There are a few factors that can exacerbate the ioend
> > > > chain
> > > > lengths, so it would be handy to have some idea of what is
> > > > actually
> > > > triggering this behaviour...
> > > >
> > > > Cheers,
> > > >
> > > > Dave.
> > >
> > > We have different reproducers. The common feature appears to be
> > > the
> > > need for a decently fast box with fairly large memory (128GB in
> > > one
> > > case, 400GB in the other). It has been reproduced with HDs, SSDs
> > > and
> > > NVME systems.
> > >
> > > On the 128GB box, we had it set up with 10+ disks in a JBOD
> > > configuration and were running the AJA system tests.
> > >
> > > On the 400GB box, we were just serially creating large (> 6GB)
> > > files
> > > using fio and that was occasionally triggering the issue. However
> > > doing
> > > an strace of that workload to disk reproduced the problem faster
> > > :-
> > > ).
> >
> > Ok, that matches up with the "lots of logically sequential dirty
> > data on a single inode in cache" vector that is required to create
> > really long bio chains on individual ioends.
> >
> > Can you try the patch below and see if addresses the issue?
> >
>
> That patch does seem to fix the soft lockups.
>
Oops... Strike that, apparently our tests just hit the following when
running on AWS with that patch.
[Wed Jan 5 20:34:46 2022] watchdog: BUG: soft lockup - CPU#4 stuck for
48s! [kworker/4:1:31315]
[Wed Jan 5 20:34:46 2022] Modules linked in: nfsv3 auth_name
bpf_preload xt_nat veth nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4
dns_resolver nfsidmap nfs fscache netfs dm_multipath nfsd auth_rpcgss
nfs_acl lockd grace sunrpc xt_MASQUERADE nf_conntrack_netlink
xt_addrtype br_netfilter bridge stp llc overlay xt_sctp
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp
nf_conntrack_ftp xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
ipt_REJECT nf_reject_ipv4 xt_conntrack ip6table_nat ip6table_mangle
ip6table_security ip6table_raw iptable_nat nf_nat iptable_mangle
iptable_security iptable_raw nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
ip_set nfnetlink ip6table_filter ip6_tables iptable_filter bonding tls
ipmi_msghandler intel_rapl_msr intel_rapl_common isst_if_common nfit
libnvdimm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i2c_piix4
rapl ip_tables xfs nvme crc32c_intel ena nvme_core
[Wed Jan 5 20:34:46 2022] CPU: 4 PID: 31315 Comm: kworker/4:1 Kdump:
loaded Tainted: G W L 5.15.12-200.pd.17718.el7.x86_64 #1
[Wed Jan 5 20:34:46 2022] Hardware name: Amazon EC2 r5b.2xlarge/, BIOS
1.0 10/16/2017
[Wed Jan 5 20:34:46 2022] Workqueue: xfs-conv/nvme1n1 xfs_end_io [xfs]
[Wed Jan 5 20:34:46 2022] RIP:
0010:_raw_spin_unlock_irqrestore+0x1c/0x20
[Wed Jan 5 20:34:46 2022] Code: 92 cc cc cc cc cc cc cc cc cc cc cc cc
cc 0f 1f 44 00 00 c6 07 00 0f 1f 40 00 f7 c6 00 02 00 00 75 01 c3 fb 66
0f 1f 44 00 00 <c3> 0f 1f 00 0f 1f 44 00 00 8b 07 a9 ff 01 00 00 75 21
b8 00 02 00
[Wed Jan 5 20:34:46 2022] RSP: 0018:ffffb9738983fd10 EFLAGS: 00000206
[Wed Jan 5 20:34:46 2022] RAX: 0000000000000001 RBX: 0000000000000db0
RCX: fffffffffffff90f
[Wed Jan 5 20:34:46 2022] RDX: ffffffffa3808938 RSI: 0000000000000206
RDI: ffffffffa3808930
[Wed Jan 5 20:34:46 2022] RBP: 0000000000000206 R08: ffffb9738601fc80
R09: ffffb9738601fc80
[Wed Jan 5 20:34:46 2022] R10: 0000000000000000 R11: 0000000000000000
R12: ffffffffa3808930
[Wed Jan 5 20:34:46 2022] R13: ffffdda3db40dd40 R14: ffff930e1c62f538
R15: ffffdda3db40dd40
[Wed Jan 5 20:34:46 2022] FS: 0000000000000000(0000)
GS:ffff93164dd00000(0000) knlGS:0000000000000000
[Wed Jan 5 20:34:46 2022] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[Wed Jan 5 20:34:46 2022] CR2: 00007ffe41f5c080 CR3: 00000005a5810001
CR4: 00000000007706e0
[Wed Jan 5 20:34:46 2022] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
[Wed Jan 5 20:34:46 2022] DR3: 0000000000000000 DR6: 00000000fffe0ff0
DR7: 0000000000000400
[Wed Jan 5 20:34:46 2022] PKRU: 55555554
[Wed Jan 5 20:34:46 2022] Call Trace:
[Wed Jan 5 20:34:46 2022] <TASK>
[Wed Jan 5 20:34:46 2022] wake_up_page_bit+0x79/0xe0
[Wed Jan 5 20:34:46 2022] end_page_writeback+0xc4/0xf0
[Wed Jan 5 20:34:46 2022] iomap_finish_ioend+0x130/0x260
[Wed Jan 5 20:34:46 2022] iomap_finish_ioends+0x71/0x90
[Wed Jan 5 20:34:46 2022] xfs_end_ioend+0x5a/0x120 [xfs]
[Wed Jan 5 20:34:46 2022] xfs_end_io+0xa1/0xc0 [xfs]
[Wed Jan 5 20:34:46 2022] process_one_work+0x1f1/0x390
[Wed Jan 5 20:34:46 2022] worker_thread+0x53/0x3e0
[Wed Jan 5 20:34:46 2022] ? process_one_work+0x390/0x390
[Wed Jan 5 20:34:46 2022] kthread+0x127/0x150
[Wed Jan 5 20:34:46 2022] ? set_kthread_struct+0x40/0x40
[Wed Jan 5 20:34:46 2022] ret_from_fork+0x22/0x30
[Wed Jan 5 20:34:46 2022] </TASK>
So it was harder to hit, but we still did eventually.
--
Trond Myklebust
CTO, Hammerspace Inc
4984 El Camino Real, Suite 208
Los Altos, CA 94022
www.hammer.space
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.IGT: failure for tests/i915/userptr: fix mapping type
From: Patchwork @ 2022-01-05 20:44 UTC (permalink / raw)
To: Matthew Auld; +Cc: igt-dev
In-Reply-To: <20220105172106.154217-1-matthew.auld@intel.com>
[-- Attachment #1: Type: text/plain, Size: 30254 bytes --]
== Series Details ==
Series: tests/i915/userptr: fix mapping type
URL : https://patchwork.freedesktop.org/series/98511/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11049_full -> IGTPW_6539_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_6539_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_6539_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
Participating hosts (13 -> 8)
------------------------------
Missing (5): pig-kbl-iris pig-glk-j5005 pig-skl-6260u shard-rkl shard-dg1
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_6539_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-untiled:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk2/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-untiled.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-untiled.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-psr:
- {shard-tglu}: NOTRUN -> [SKIP][3] +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglu-5/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- {shard-tglu}: NOTRUN -> [FAIL][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglu-3/igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a.html
Known issues
------------
Here are the changes found in IGTPW_6539_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-iclb: NOTRUN -> [DMESG-WARN][5] ([i915#3002])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@gem_create@create-massive.html
- shard-tglb: NOTRUN -> [DMESG-WARN][6] ([i915#3002])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb8/igt@gem_create@create-massive.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#232]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-tglb7/igt@gem_eio@unwedge-stress.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb2/igt@gem_eio@unwedge-stress.html
- shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#2481] / [i915#3070])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb5/igt@gem_eio@unwedge-stress.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb5/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb7/igt@gem_exec_fair@basic-none-share@rcs0.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb6/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl3/igt@gem_exec_fair@basic-pace@vecs0.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb2/igt@gem_exec_fair@basic-throttle@rcs0.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb8/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_exec_whisper@basic-fds-forked:
- shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118]) +2 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk6/igt@gem_exec_whisper@basic-fds-forked.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk3/igt@gem_exec_whisper@basic-fds-forked.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +1 similar issue
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl2/igt@gem_lmem_swapping@heavy-verify-random.html
* igt@gem_lmem_swapping@parallel-random:
- shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl3/igt@gem_lmem_swapping@parallel-random.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#4613]) +1 similar issue
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb5/igt@gem_lmem_swapping@parallel-random-verify.html
* igt@gem_lmem_swapping@smem-oom:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#4613])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb8/igt@gem_lmem_swapping@smem-oom.html
* igt@gem_pread@exhaustion:
- shard-apl: NOTRUN -> [WARN][23] ([i915#2658])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl1/igt@gem_pread@exhaustion.html
* igt@gem_render_copy@x-tiled-to-vebox-yf-tiled:
- shard-kbl: NOTRUN -> [SKIP][24] ([fdo#109271]) +196 similar issues
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl1/igt@gem_render_copy@x-tiled-to-vebox-yf-tiled.html
* igt@gem_render_copy@yf-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][25] ([i915#768]) +1 similar issue
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb4/igt@gem_render_copy@yf-tiled-to-vebox-y-tiled.html
* igt@gem_userptr_blits@coherency-unsync:
- shard-tglb: NOTRUN -> [SKIP][26] ([i915#3297])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb7/igt@gem_userptr_blits@coherency-unsync.html
- shard-iclb: NOTRUN -> [SKIP][27] ([i915#3297])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb4/igt@gem_userptr_blits@coherency-unsync.html
* igt@i915_pm_dc@dc6-dpms:
- shard-kbl: NOTRUN -> [FAIL][28] ([i915#454])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl4/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl: [PASS][29] -> [DMESG-WARN][30] ([i915#180]) +2 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@kms_big_fb@linear-64bpp-rotate-90:
- shard-iclb: NOTRUN -> [SKIP][31] ([fdo#110725] / [fdo#111614])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb5/igt@kms_big_fb@linear-64bpp-rotate-90.html
- shard-tglb: NOTRUN -> [SKIP][32] ([fdo#111614])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb2/igt@kms_big_fb@linear-64bpp-rotate-90.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-glk: NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#3777])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk3/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-kbl: NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#3777])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl4/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
- shard-apl: NOTRUN -> [SKIP][35] ([fdo#109271]) +144 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl3/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-tglb: NOTRUN -> [SKIP][36] ([fdo#111615]) +1 similar issue
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb8/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
- shard-iclb: NOTRUN -> [SKIP][37] ([fdo#110723])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][38] ([fdo#109271] / [i915#3886]) +4 similar issues
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl1/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
- shard-glk: NOTRUN -> [SKIP][39] ([fdo#109271] / [i915#3886])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk5/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
- shard-iclb: NOTRUN -> [SKIP][40] ([fdo#109278] / [i915#3886])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-bad-aux-stride-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][41] ([fdo#111615] / [i915#3689])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb5/igt@kms_ccs@pipe-b-bad-aux-stride-yf_tiled_ccs.html
* igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-kbl: NOTRUN -> [SKIP][42] ([fdo#109271] / [i915#3886]) +10 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl4/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][43] ([i915#3689] / [i915#3886])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb3/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium@hdmi-edid-change-during-suspend:
- shard-apl: NOTRUN -> [SKIP][44] ([fdo#109271] / [fdo#111827]) +13 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl8/igt@kms_chamelium@hdmi-edid-change-during-suspend.html
- shard-tglb: NOTRUN -> [SKIP][45] ([fdo#109284] / [fdo#111827]) +2 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb1/igt@kms_chamelium@hdmi-edid-change-during-suspend.html
- shard-glk: NOTRUN -> [SKIP][46] ([fdo#109271] / [fdo#111827]) +1 similar issue
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk8/igt@kms_chamelium@hdmi-edid-change-during-suspend.html
* igt@kms_color_chamelium@pipe-a-ctm-blue-to-red:
- shard-kbl: NOTRUN -> [SKIP][47] ([fdo#109271] / [fdo#111827]) +17 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl3/igt@kms_color_chamelium@pipe-a-ctm-blue-to-red.html
* igt@kms_color_chamelium@pipe-c-ctm-limited-range:
- shard-snb: NOTRUN -> [SKIP][48] ([fdo#109271] / [fdo#111827]) +1 similar issue
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-snb7/igt@kms_color_chamelium@pipe-c-ctm-limited-range.html
- shard-iclb: NOTRUN -> [SKIP][49] ([fdo#109284] / [fdo#111827]) +1 similar issue
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb6/igt@kms_color_chamelium@pipe-c-ctm-limited-range.html
* igt@kms_content_protection@atomic-dpms:
- shard-kbl: NOTRUN -> [TIMEOUT][50] ([i915#1319])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl7/igt@kms_content_protection@atomic-dpms.html
* igt@kms_content_protection@srm:
- shard-apl: NOTRUN -> [TIMEOUT][51] ([i915#1319])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl1/igt@kms_content_protection@srm.html
* igt@kms_cursor_crc@pipe-a-cursor-max-size-sliding:
- shard-iclb: NOTRUN -> [SKIP][52] ([fdo#109278]) +6 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb8/igt@kms_cursor_crc@pipe-a-cursor-max-size-sliding.html
- shard-tglb: NOTRUN -> [SKIP][53] ([i915#3359])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb6/igt@kms_cursor_crc@pipe-a-cursor-max-size-sliding.html
* igt@kms_cursor_crc@pipe-d-cursor-32x32-sliding:
- shard-tglb: NOTRUN -> [SKIP][54] ([i915#3319])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb5/igt@kms_cursor_crc@pipe-d-cursor-32x32-sliding.html
* igt@kms_cursor_crc@pipe-d-cursor-512x512-sliding:
- shard-tglb: NOTRUN -> [SKIP][55] ([fdo#109279] / [i915#3359]) +1 similar issue
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb5/igt@kms_cursor_crc@pipe-d-cursor-512x512-sliding.html
* igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
- shard-tglb: NOTRUN -> [SKIP][56] ([fdo#109274] / [fdo#111825]) +2 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb5/igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-iclb: NOTRUN -> [SKIP][57] ([fdo#109274] / [fdo#109278]) +1 similar issue
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb1/igt@kms_cursor_legacy@cursorb-vs-flipa-toggle.html
* igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy:
- shard-snb: [PASS][58] -> [SKIP][59] ([fdo#109271]) +1 similar issue
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-snb5/igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-snb6/igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy.html
* igt@kms_draw_crc@draw-method-rgb565-blt-untiled:
- shard-glk: [PASS][60] -> [FAIL][61] ([i915#1888] / [i915#3451])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-blt-untiled.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-blt-untiled.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][62] -> [INCOMPLETE][63] ([i915#180] / [i915#636])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1:
- shard-glk: [PASS][64] -> [FAIL][65] ([i915#79])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk3/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk3/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1.html
* igt@kms_flip@flip-vs-expired-vblank@c-dp1:
- shard-kbl: [PASS][66] -> [FAIL][67] ([i915#79])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl6/igt@kms_flip@flip-vs-expired-vblank@c-dp1.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl1/igt@kms_flip@flip-vs-expired-vblank@c-dp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl: NOTRUN -> [DMESG-WARN][68] ([i915#180]) +3 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl7/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: [PASS][69] -> [DMESG-WARN][70] ([i915#180]) +5 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl3/igt@kms_flip@flip-vs-suspend@c-dp1.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl1/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling:
- shard-glk: [PASS][71] -> [FAIL][72] ([i915#4911])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk9/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling:
- shard-iclb: [PASS][73] -> [SKIP][74] ([i915#3701])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb7/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-render:
- shard-iclb: NOTRUN -> [SKIP][75] ([fdo#109280]) +8 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-rte:
- shard-glk: NOTRUN -> [SKIP][76] ([fdo#109271]) +18 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk6/igt@kms_frontbuffer_tracking@fbcpsr-2p-rte.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-cpu:
- shard-tglb: NOTRUN -> [SKIP][77] ([fdo#109280] / [fdo#111825]) +12 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt:
- shard-snb: NOTRUN -> [SKIP][78] ([fdo#109271]) +20 similar issues
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-snb2/igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-kbl: NOTRUN -> [FAIL][79] ([fdo#108145] / [i915#265]) +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl6/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-apl: NOTRUN -> [FAIL][80] ([fdo#108145] / [i915#265]) +2 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl4/igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-glk: NOTRUN -> [FAIL][81] ([i915#265])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk8/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
- shard-apl: NOTRUN -> [FAIL][82] ([i915#265])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl8/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_plane_lowres@pipe-d-tiling-yf:
- shard-tglb: NOTRUN -> [SKIP][83] ([fdo#111615] / [fdo#112054])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb8/igt@kms_plane_lowres@pipe-d-tiling-yf.html
* igt@kms_psr2_sf@cursor-plane-update-sf:
- shard-apl: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#658])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl4/igt@kms_psr2_sf@cursor-plane-update-sf.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-kbl: NOTRUN -> [SKIP][85] ([fdo#109271] / [i915#658]) +3 similar issues
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl4/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
* igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [PASS][86] -> [SKIP][87] ([fdo#109441]) +1 similar issue
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb3/igt@kms_psr@psr2_cursor_plane_onoff.html
* igt@kms_psr@psr2_sprite_render:
- shard-tglb: NOTRUN -> [FAIL][88] ([i915#132] / [i915#3467])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb6/igt@kms_psr@psr2_sprite_render.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-kbl: NOTRUN -> [SKIP][89] ([fdo#109271] / [i915#533]) +1 similar issue
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl3/igt@kms_vblank@pipe-d-wait-idle.html
- shard-apl: NOTRUN -> [SKIP][90] ([fdo#109271] / [i915#533])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl2/igt@kms_vblank@pipe-d-wait-idle.html
* igt@kms_writeback@writeback-fb-id:
- shard-apl: NOTRUN -> [SKIP][91] ([fdo#109271] / [i915#2437]) +1 similar issue
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl2/igt@kms_writeback@writeback-fb-id.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-kbl: NOTRUN -> [SKIP][92] ([fdo#109271] / [i915#2437]) +1 similar issue
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl7/igt@kms_writeback@writeback-pixel-formats.html
* igt@nouveau_crc@pipe-b-ctx-flip-detection:
- shard-tglb: NOTRUN -> [SKIP][93] ([i915#2530]) +1 similar issue
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb7/igt@nouveau_crc@pipe-b-ctx-flip-detection.html
- shard-iclb: NOTRUN -> [SKIP][94] ([i915#2530])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb1/igt@nouveau_crc@pipe-b-ctx-flip-detection.html
* igt@sysfs_clients@recycle-many:
- shard-apl: NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#2994]) +1 similar issue
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl1/igt@sysfs_clients@recycle-many.html
- shard-kbl: NOTRUN -> [SKIP][96] ([fdo#109271] / [i915#2994]) +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl1/igt@sysfs_clients@recycle-many.html
#### Possible fixes ####
* igt@gem_eio@in-flight-contexts-10ms:
- {shard-tglu}: [TIMEOUT][97] ([i915#3063]) -> [PASS][98]
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-tglu-1/igt@gem_eio@in-flight-contexts-10ms.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglu-3/igt@gem_eio@in-flight-contexts-10ms.html
* igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [SKIP][99] ([i915#4525]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb8/igt@gem_exec_balancer@parallel-bb-first.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@gem_exec_balancer@parallel-bb-first.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [FAIL][101] ([i915#2842]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-apl7/igt@gem_exec_fair@basic-none@vecs0.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl3/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [FAIL][103] ([i915#2842]) -> [PASS][104]
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-tglb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglb7/igt@gem_exec_fair@basic-pace-share@rcs0.html
- shard-glk: [FAIL][105] ([i915#2842]) -> [PASS][106] +1 similar issue
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk4/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl: [FAIL][107] ([i915#2842]) -> [PASS][108] +1 similar issue
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl3/igt@gem_exec_fair@basic-pace@vcs1.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_schedule@preempt-queue-contexts-chain@vecs0:
- {shard-tglu}: [DMESG-WARN][109] -> [PASS][110] +3 similar issues
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-tglu-7/igt@gem_exec_schedule@preempt-queue-contexts-chain@vecs0.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglu-6/igt@gem_exec_schedule@preempt-queue-contexts-chain@vecs0.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [DMESG-WARN][111] ([i915#180]) -> [PASS][112] +3 similar issues
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-apl8/igt@gem_softpin@noreloc-s3.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl6/igt@gem_softpin@noreloc-s3.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][113] ([i915#454]) -> [PASS][114]
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
* igt@i915_suspend@sysfs-reader:
- shard-kbl: [DMESG-WARN][115] ([i915#180]) -> [PASS][116] +5 similar issues
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl7/igt@i915_suspend@sysfs-reader.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl4/igt@i915_suspend@sysfs-reader.html
* igt@kms_big_fb@linear-16bpp-rotate-180:
- {shard-tglu}: [DMESG-WARN][117] ([i915#402]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-tglu-6/igt@kms_big_fb@linear-16bpp-rotate-180.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglu-8/igt@kms_big_fb@linear-16bpp-rotate-180.html
* igt@kms_big_fb@linear-32bpp-rotate-180:
- shard-glk: [DMESG-WARN][119] ([i915#118]) -> [PASS][120] +6 similar issues
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk2/igt@kms_big_fb@linear-32bpp-rotate-180.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk1/igt@kms_big_fb@linear-32bpp-rotate-180.html
* igt@kms_cursor_legacy@flip-vs-cursor-varying-size:
- shard-iclb: [FAIL][121] ([i915#2346]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb1/igt@kms_cursor_legacy@flip-vs-cursor-varying-size.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [INCOMPLETE][123] ([i915#180] / [i915#1982]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-apl4/igt@kms_fbcon_fbt@fbc-suspend.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-apl2/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@absolute-wf_vblank-interruptible@a-edp1:
- shard-iclb: [DMESG-WARN][125] ([i915#4391]) -> [PASS][126]
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb7/igt@kms_flip@absolute-wf_vblank-interruptible@a-edp1.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb6/igt@kms_flip@absolute-wf_vblank-interruptible@a-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling:
- shard-glk: [FAIL][127] ([i915#4911]) -> [PASS][128]
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk3/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [SKIP][129] ([fdo#109441]) -> [PASS][130] +2 similar issues
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb6/igt@kms_psr@psr2_suspend.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb2/igt@kms_psr@psr2_suspend.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [DMESG-WARN][131] ([i915#180] / [i915#295]) -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-kbl7/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@prime_busy@hang@vecs0:
- {shard-tglu}: [INCOMPLETE][133] -> [PASS][134] +1 similar issue
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-tglu-7/igt@prime_busy@hang@vecs0.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-tglu-5/igt@prime_busy@hang@vecs0.html
#### Warnings ####
* igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [FAIL][135] ([i915#4916]) -> [SKIP][136] ([i915#4525])
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-iclb1/igt@gem_exec_balancer@parallel-ordering.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-iclb8/igt@gem_exec_balancer@parallel-ordering.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][137] ([i915#2851]) -> [FAIL][138] ([i915#2842])
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/shard-glk3/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/shard-glk5/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: [WARN][139] ([i915#1804] / [i915#2684]) -> [WARN][140] ([i915#2684])
[139]: https://int
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
[-- Attachment #2: Type: text/html, Size: 33534 bytes --]
^ permalink raw reply
* [PATCH v2 4/7] target/ppc: Add HV support to ppc_interrupts_little_endian
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
The ppc_interrupts_little_endian function could be used for interrupts
delivered in Hypervisor mode, so add support for powernv8 and powernv9
to it.
Also drop the comment because it is inaccurate, all CPUs that can run
little endian can have interrupts in little endian. The point is
whether they can take interrupts in an endianness different from
MSR_LE.
This change has no functional impact.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
target/ppc/arch_dump.c | 2 +-
target/ppc/cpu.h | 23 +++++++++++++++--------
target/ppc/excp_helper.c | 2 +-
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/target/ppc/arch_dump.c b/target/ppc/arch_dump.c
index bb392f6d88..12cde198a3 100644
--- a/target/ppc/arch_dump.c
+++ b/target/ppc/arch_dump.c
@@ -237,7 +237,7 @@ int cpu_get_dump_info(ArchDumpInfo *info,
info->d_machine = PPC_ELF_MACHINE;
info->d_class = ELFCLASS;
- if (ppc_interrupts_little_endian(cpu)) {
+ if (ppc_interrupts_little_endian(cpu, false)) {
info->d_endian = ELFDATA2LSB;
} else {
info->d_endian = ELFDATA2MSB;
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index f20d4ffa6d..a6fc857ad4 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -2728,20 +2728,27 @@ static inline bool ppc_has_spr(PowerPCCPU *cpu, int spr)
return cpu->env.spr_cb[spr].name != NULL;
}
-static inline bool ppc_interrupts_little_endian(PowerPCCPU *cpu)
+#if !defined(CONFIG_USER_ONLY)
+static inline bool ppc_interrupts_little_endian(PowerPCCPU *cpu, bool hv)
{
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+ CPUPPCState *env = &cpu->env;
+ bool ile = false;
- /*
- * Only models that have an LPCR and know about LPCR_ILE can do little
- * endian.
- */
- if (pcc->lpcr_mask & LPCR_ILE) {
- return !!(cpu->env.spr[SPR_LPCR] & LPCR_ILE);
+ if (hv && env->has_hv_mode) {
+ if (is_isa300(pcc)) {
+ ile = !!(env->spr[SPR_HID0] & HID0_POWER9_HILE);
+ } else {
+ ile = !!(env->spr[SPR_HID0] & HID0_HILE);
+ }
+
+ } else if (pcc->lpcr_mask & LPCR_ILE) {
+ ile = !!(env->spr[SPR_LPCR] & LPCR_ILE);
}
- return false;
+ return ile;
}
+#endif
void dump_mmu(CPUPPCState *env);
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index fa41f8048d..92953af896 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -1071,7 +1071,7 @@ void ppc_cpu_do_fwnmi_machine_check(CPUState *cs, target_ulong vector)
*/
msr = (1ULL << MSR_ME);
msr |= env->msr & (1ULL << MSR_SF);
- if (ppc_interrupts_little_endian(cpu)) {
+ if (ppc_interrupts_little_endian(cpu, false)) {
msr |= (1ULL << MSR_LE);
}
--
2.33.1
^ permalink raw reply related
* [PATCH v2 3/7] target/ppc: powerpc_excp: Group unimplemented exceptions
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
target/ppc/excp_helper.c | 77 +++++-----------------------------------
1 file changed, 8 insertions(+), 69 deletions(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index ce86b2ae37..fa41f8048d 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -701,23 +701,6 @@ static void powerpc_excp(PowerPCCPU *cpu, int excp)
case POWERPC_EXCP_SPEU: /* SPE/embedded floating-point unavailable/VPU */
env->spr[SPR_BOOKE_ESR] = ESR_SPV;
break;
- case POWERPC_EXCP_EFPDI: /* Embedded floating-point data interrupt */
- /* XXX: TODO */
- cpu_abort(cs, "Embedded floating point data exception "
- "is not implemented yet !\n");
- env->spr[SPR_BOOKE_ESR] = ESR_SPV;
- break;
- case POWERPC_EXCP_EFPRI: /* Embedded floating-point round interrupt */
- /* XXX: TODO */
- cpu_abort(cs, "Embedded floating point round exception "
- "is not implemented yet !\n");
- env->spr[SPR_BOOKE_ESR] = ESR_SPV;
- break;
- case POWERPC_EXCP_EPERFM: /* Embedded performance monitor interrupt */
- /* XXX: TODO */
- cpu_abort(cs,
- "Performance counter exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_DOORI: /* Embedded doorbell interrupt */
break;
case POWERPC_EXCP_DOORCI: /* Embedded doorbell critical interrupt */
@@ -782,19 +765,6 @@ static void powerpc_excp(PowerPCCPU *cpu, int excp)
case POWERPC_EXCP_PIT: /* Programmable interval timer interrupt */
trace_ppc_excp_print("PIT");
break;
- case POWERPC_EXCP_IO: /* IO error exception */
- /* XXX: TODO */
- cpu_abort(cs, "601 IO error exception is not implemented yet !\n");
- break;
- case POWERPC_EXCP_RUNM: /* Run mode exception */
- /* XXX: TODO */
- cpu_abort(cs, "601 run mode exception is not implemented yet !\n");
- break;
- case POWERPC_EXCP_EMUL: /* Emulation trap exception */
- /* XXX: TODO */
- cpu_abort(cs, "602 emulation trap exception "
- "is not implemented yet !\n");
- break;
case POWERPC_EXCP_IFTLB: /* Instruction fetch TLB error */
case POWERPC_EXCP_DLTLB: /* Data load TLB miss */
case POWERPC_EXCP_DSTLB: /* Data store TLB miss */
@@ -821,56 +791,25 @@ static void powerpc_excp(PowerPCCPU *cpu, int excp)
break;
}
break;
+ case POWERPC_EXCP_EFPDI: /* Embedded floating-point data interrupt */
+ case POWERPC_EXCP_EFPRI: /* Embedded floating-point round interrupt */
+ case POWERPC_EXCP_EPERFM: /* Embedded performance monitor interrupt */
+ case POWERPC_EXCP_IO: /* IO error exception */
+ case POWERPC_EXCP_RUNM: /* Run mode exception */
+ case POWERPC_EXCP_EMUL: /* Emulation trap exception */
case POWERPC_EXCP_FPA: /* Floating-point assist exception */
- /* XXX: TODO */
- cpu_abort(cs, "Floating point assist exception "
- "is not implemented yet !\n");
- break;
case POWERPC_EXCP_DABR: /* Data address breakpoint */
- /* XXX: TODO */
- cpu_abort(cs, "DABR exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_IABR: /* Instruction address breakpoint */
- /* XXX: TODO */
- cpu_abort(cs, "IABR exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_SMI: /* System management interrupt */
- /* XXX: TODO */
- cpu_abort(cs, "SMI exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_THERM: /* Thermal interrupt */
- /* XXX: TODO */
- cpu_abort(cs, "Thermal management exception "
- "is not implemented yet !\n");
- break;
case POWERPC_EXCP_PERFM: /* Embedded performance monitor interrupt */
- /* XXX: TODO */
- cpu_abort(cs,
- "Performance counter exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_VPUA: /* Vector assist exception */
- /* XXX: TODO */
- cpu_abort(cs, "VPU assist exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_SOFTP: /* Soft patch exception */
- /* XXX: TODO */
- cpu_abort(cs,
- "970 soft-patch exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_MAINT: /* Maintenance exception */
- /* XXX: TODO */
- cpu_abort(cs,
- "970 maintenance exception is not implemented yet !\n");
- break;
case POWERPC_EXCP_MEXTBR: /* Maskable external breakpoint */
- /* XXX: TODO */
- cpu_abort(cs, "Maskable external exception "
- "is not implemented yet !\n");
- break;
case POWERPC_EXCP_NMEXTBR: /* Non maskable external breakpoint */
- /* XXX: TODO */
- cpu_abort(cs, "Non maskable external exception "
- "is not implemented yet !\n");
+ cpu_abort(cs, "%s exception not implemented\n",
+ powerpc_excp_name(excp));
break;
default:
excp_invalid:
--
2.33.1
^ permalink raw reply related
* [PATCH v2 1/7] target/ppc: powerpc_excp: Extract software TLB logging into a function
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
In-Reply-To: <20220105204029.4058500-1-farosas@linux.ibm.com>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
target/ppc/excp_helper.c | 63 +++++++++++++++++++++++-----------------
1 file changed, 36 insertions(+), 27 deletions(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index a779dc936a..2c5d5470de 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -135,6 +135,41 @@ static void dump_hcall(CPUPPCState *env)
env->nip);
}
+static void ppc_excp_debug_sw_tlb(CPUPPCState *env, int excp)
+{
+#if defined(DEBUG_SOFTWARE_TLB)
+ const char *es;
+ target_ulong *miss, *cmp;
+ int en;
+
+ if (!qemu_log_enabled()) {
+ return;
+ }
+
+ if (excp == POWERPC_EXCP_IFTLB) {
+ es = "I";
+ en = 'I';
+ miss = &env->spr[SPR_IMISS];
+ cmp = &env->spr[SPR_ICMP];
+ } else {
+ if (excp == POWERPC_EXCP_DLTLB) {
+ es = "DL";
+ } else {
+ es = "DS";
+ }
+ en = 'D';
+ miss = &env->spr[SPR_DMISS];
+ cmp = &env->spr[SPR_DCMP];
+ }
+ qemu_log("6xx %sTLB miss: %cM " TARGET_FMT_lx " %cC "
+ TARGET_FMT_lx " H1 " TARGET_FMT_lx " H2 "
+ TARGET_FMT_lx " %08x\n", es, en, *miss, en, *cmp,
+ env->spr[SPR_HASH1], env->spr[SPR_HASH2],
+ env->error_code);
+#endif
+}
+
+
static int powerpc_reset_wakeup(CPUState *cs, CPUPPCState *env, int excp,
target_ulong *msr)
{
@@ -777,34 +812,8 @@ static void powerpc_excp(PowerPCCPU *cpu, int excp)
}
/* fall through */
case POWERPC_EXCP_7x5:
-#if defined(DEBUG_SOFTWARE_TLB)
- if (qemu_log_enabled()) {
- const char *es;
- target_ulong *miss, *cmp;
- int en;
+ ppc_excp_debug_sw_tlb(env, excp);
- if (excp == POWERPC_EXCP_IFTLB) {
- es = "I";
- en = 'I';
- miss = &env->spr[SPR_IMISS];
- cmp = &env->spr[SPR_ICMP];
- } else {
- if (excp == POWERPC_EXCP_DLTLB) {
- es = "DL";
- } else {
- es = "DS";
- }
- en = 'D';
- miss = &env->spr[SPR_DMISS];
- cmp = &env->spr[SPR_DCMP];
- }
- qemu_log("6xx %sTLB miss: %cM " TARGET_FMT_lx " %cC "
- TARGET_FMT_lx " H1 " TARGET_FMT_lx " H2 "
- TARGET_FMT_lx " %08x\n", es, en, *miss, en, *cmp,
- env->spr[SPR_HASH1], env->spr[SPR_HASH2],
- env->error_code);
- }
-#endif
msr |= env->crf[0] << 28;
msr |= env->error_code; /* key, D/I, S/L bits */
/* Set way using a LRU mechanism */
--
2.33.1
^ permalink raw reply related
* Re: [PATCH] Revert "clk: Detect failure to set defaults"
From: Fabio Estevam @ 2022-01-05 20:43 UTC (permalink / raw)
To: Marek Vasut; +Cc: U-Boot-Denx, Peng Fan, Simon Glass
In-Reply-To: <20220101185139.470786-1-marex@denx.de>
Hi Marek,
On Sat, Jan 1, 2022 at 3:51 PM Marek Vasut <marex@denx.de> wrote:
>
> This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> The aforementioned patch causes massive breakage on all platforms which
> have 'assigned-clock' DT property in their DT which references any clock
> that are not supported by the platform clock driver. That can easily
> happen either in SPL, or because the clock driver is reduced. Currently
> it seems all iMX8M are affected and fail to boot altogether.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Peng Fan <peng.fan@oss.nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
^ permalink raw reply
* [PATCH v2 0/7] target/ppc: powerpc_excp improvements (2/n)
From: Fabiano Rosas @ 2022-01-05 20:40 UTC (permalink / raw)
To: qemu-devel; +Cc: richard.henderson, danielhb413, qemu-ppc, clg, david
This is version two of the second batch of cleanups to powerpc_excp. I
have started using powerpc_excp_name for the unimplemented messages,
solved the POWERPC_EXCP_970 conundrum by ignoring it and left AIL and
ILE separated because that can be done in the Book3S series where it
will make more sense.
- patch 1,2: unchanged;
- patch 3: group unimplemented messages and use powerpc_excp_name;
- patch 4: add HV support to ppc_interrupts_little_endian but now
check has_hv_mode in case anyone passes hv=true by mistake;
- patch 5: add MSR_ILE support to ppc_interrupts_little_endian, this
avoids having to check excp_model in the next patch;
- patch 6: use ppc_interrupts_little_endian in powerpc_excp but this
time not only for >= 970, but for all CPUs;
- patch 7: unchanged.
this series v1:
https://lists.nongnu.org/archive/html/qemu-ppc/2022-01/msg00054.html
RFC v1:
https://lists.nongnu.org/archive/html/qemu-ppc/2021-06/msg00026.html
RFC v2:
https://lists.nongnu.org/archive/html/qemu-ppc/2021-12/msg00542.html
Cleanups 1/n [already merged]:
https://mail.gnu.org/archive/html/qemu-ppc/2021-12/msg00696.html
Fabiano Rosas (7):
target/ppc: powerpc_excp: Extract software TLB logging into a function
target/ppc: powerpc_excp: Keep 60x soft MMU logs active
target/ppc: powerpc_excp: Group unimplemented exceptions
target/ppc: Add HV support to ppc_interrupts_little_endian
target/ppc: Add MSR_ILE support to ppc_interrupts_little_endian
target/ppc: Use ppc_interrupts_little_endian in powerpc_excp
target/ppc: Introduce a wrapper for powerpc_excp
target/ppc/arch_dump.c | 2 +-
target/ppc/cpu.h | 25 ++++--
target/ppc/excp_helper.c | 184 ++++++++++++---------------------------
3 files changed, 74 insertions(+), 137 deletions(-)
--
2.33.1
^ permalink raw reply
* Re: [PATCH 3/8] device property: Helper to match multiple connections
From: Bjorn Andersson @ 2022-01-05 20:43 UTC (permalink / raw)
To: Sakari Ailus
Cc: Heikki Krogerus, Kishon Vijay Abraham I, Vinod Koul, Rob Herring,
Greg Kroah-Hartman, Hans de Goede, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, linux-arm-msm, linux-phy,
devicetree, linux-kernel, linux-usb
In-Reply-To: <Yc7I3gZehc1lHn4Z@paasikivi.fi.intel.com>
On Fri 31 Dec 01:09 PST 2021, Sakari Ailus wrote:
> Hi Björn,
>
> (And thanks to Heikki for cc'ing me!)
>
> On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
> > +Andy, Dan and Sakari
> >
> > On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
> > > In some cases multiple connections with the same connection id
> > > needs to be resolved from a fwnode graph.
> > >
> > > One such example is when separate hardware is used for performing muxing and/or
> > > orientation switching of the SuperSpeed and SBU lines in a USB-C
> > > connector. In this case the connector needs to belong to a graph with
> > > multiple matching remote endpoints, and the TypeC controller needs to be
> > > able to resolve them both.
> > >
> > > Add a new API that allows this kind of lookup.
> > >
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > > drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
> > > include/linux/property.h | 5 +++
> > > 2 files changed, 99 insertions(+)
> > >
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index cbe4fa298413..0aa0296fd991 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -1180,6 +1180,36 @@ fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > > return NULL;
> > > }
> > >
> > > +static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches,
> > > + unsigned int matches_len)
> > > +{
> > > + struct fwnode_handle *node;
> > > + struct fwnode_handle *ep;
> > > + unsigned int count = 0;
> > > + void *ret;
> > > +
> > > + fwnode_graph_for_each_endpoint(fwnode, ep) {
> > > + if (count >= matches_len) {
> > > + fwnode_handle_put(ep);
> > > + return count;
> > > + }
> > > +
> > > + node = fwnode_graph_get_remote_port_parent(ep);
> > > + if (!fwnode_device_is_available(node))
>
> The reference to node needs to be put here.
>
You're right, thanks!
> > > + continue;
> > > +
> > > + ret = match(node, con_id, data);
> > > + fwnode_handle_put(node);
> > > +
> > > + if (ret)
> > > + matches[count++] = ret;
> > > + }
> > > + return count;
> > > +}
> > > +
> > > static void *
> > > fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > > void *data, devcon_match_fn_t match)
> > > @@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > > return NULL;
> > > }
> > >
> > > +static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches,
> > > + unsigned int matches_len)
> > > +{
> > > + struct fwnode_handle *node;
> > > + unsigned int count = 0;
> > > + void *ret;
> > > + int i;
>
> unsigned int, please.
>
Sounds good.
> > > +
> > > + for (i = 0; ; i++) {
> > > + if (count >= matches_len)
> > > + return count;
> > > +
> > > + node = fwnode_find_reference(fwnode, con_id, i);
> > > + if (IS_ERR(node))
> > > + break;
> > > +
> > > + ret = match(node, NULL, data);
> > > + fwnode_handle_put(node);
> > > +
> > > + if (ret)
> > > + matches[count++] = ret;
> > > + }
> > > +
> > > + return count;
> > > +}
> > > +
> > > /**
> > > * fwnode_connection_find_match - Find connection from a device node
> > > * @fwnode: Device node with the connection
> > > @@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
> > > return fwnode_devcon_match(fwnode, con_id, data, match);
> > > }
> > > EXPORT_SYMBOL_GPL(fwnode_connection_find_match);
> > > +
> > > +/**
> > > + * fwnode_connection_find_matches - Find connections from a device node
> > > + * @fwnode: Device node with the connection
> > > + * @con_id: Identifier for the connection
> > > + * @data: Data for the match function
> > > + * @match: Function to check and convert the connection description
> > > + * @matches: Array of pointers to fill with matches
> > > + * @matches_len: Length of @matches
> > > + *
> > > + * Find up to @matches_len connections with unique identifier @con_id between
> > > + * @fwnode and other device nodes. @match will be used to convert the
> > > + * connection description to data the caller is expecting to be returned
> > > + * through the @matches array.
>
> If the caller allocates the matches array, how does it know how large it
> should be? Is there a need to provide a way to count the matches before
> writing them to an array? Most similar functions do that by just setting the
> array (matches) to NULL.
>
This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.
I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.
But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.
As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.
I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.
But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.
While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.
As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?
Regards,
Bjorn
> > > + *
> > > + * Return: Number of matches resolved, of negative errno.
> > > + */
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches, unsigned int matches_len)
> > > +{
> > > + unsigned int count;
> > > +
> > > + if (!fwnode || !match || !matches)
> > > + return -EINVAL;
> > > +
> > > + count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> > > + matches, matches_len);
> > > +
> > > + return count + fwnode_devcon_matches(fwnode, con_id, data, match,
> > > + matches + count,
> > > + matches_len - count);
> > > +}
> > > +EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
> > > diff --git a/include/linux/property.h b/include/linux/property.h
> > > index 16f736c698a2..59484ccb260e 100644
> > > --- a/include/linux/property.h
> > > +++ b/include/linux/property.h
> > > @@ -444,6 +444,11 @@ static inline void *device_connection_find_match(struct device *dev,
> > > return fwnode_connection_find_match(dev_fwnode(dev), con_id, data, match);
> > > }
> > >
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches, unsigned int matches_len);
> > > +
> > > /* -------------------------------------------------------------------------- */
> > > /* Software fwnode support - when HW description is incomplete or missing */
> > >
>
> --
> Kind regards,
>
> Sakari Ailus
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/8] device property: Helper to match multiple connections
From: Bjorn Andersson @ 2022-01-05 20:43 UTC (permalink / raw)
To: Sakari Ailus
Cc: Heikki Krogerus, Kishon Vijay Abraham I, Vinod Koul, Rob Herring,
Greg Kroah-Hartman, Hans de Goede, Rafael J. Wysocki,
Andy Shevchenko, Daniel Scally, linux-arm-msm, linux-phy,
devicetree, linux-kernel, linux-usb
In-Reply-To: <Yc7I3gZehc1lHn4Z@paasikivi.fi.intel.com>
On Fri 31 Dec 01:09 PST 2021, Sakari Ailus wrote:
> Hi Björn,
>
> (And thanks to Heikki for cc'ing me!)
>
> On Thu, Dec 30, 2021 at 11:26:34AM +0200, Heikki Krogerus wrote:
> > +Andy, Dan and Sakari
> >
> > On Mon, Dec 27, 2021 at 09:21:11PM -0800, Bjorn Andersson wrote:
> > > In some cases multiple connections with the same connection id
> > > needs to be resolved from a fwnode graph.
> > >
> > > One such example is when separate hardware is used for performing muxing and/or
> > > orientation switching of the SuperSpeed and SBU lines in a USB-C
> > > connector. In this case the connector needs to belong to a graph with
> > > multiple matching remote endpoints, and the TypeC controller needs to be
> > > able to resolve them both.
> > >
> > > Add a new API that allows this kind of lookup.
> > >
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > > drivers/base/property.c | 94 ++++++++++++++++++++++++++++++++++++++++
> > > include/linux/property.h | 5 +++
> > > 2 files changed, 99 insertions(+)
> > >
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index cbe4fa298413..0aa0296fd991 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -1180,6 +1180,36 @@ fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > > return NULL;
> > > }
> > >
> > > +static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches,
> > > + unsigned int matches_len)
> > > +{
> > > + struct fwnode_handle *node;
> > > + struct fwnode_handle *ep;
> > > + unsigned int count = 0;
> > > + void *ret;
> > > +
> > > + fwnode_graph_for_each_endpoint(fwnode, ep) {
> > > + if (count >= matches_len) {
> > > + fwnode_handle_put(ep);
> > > + return count;
> > > + }
> > > +
> > > + node = fwnode_graph_get_remote_port_parent(ep);
> > > + if (!fwnode_device_is_available(node))
>
> The reference to node needs to be put here.
>
You're right, thanks!
> > > + continue;
> > > +
> > > + ret = match(node, con_id, data);
> > > + fwnode_handle_put(node);
> > > +
> > > + if (ret)
> > > + matches[count++] = ret;
> > > + }
> > > + return count;
> > > +}
> > > +
> > > static void *
> > > fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > > void *data, devcon_match_fn_t match)
> > > @@ -1202,6 +1232,35 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
> > > return NULL;
> > > }
> > >
> > > +static unsigned int fwnode_devcon_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches,
> > > + unsigned int matches_len)
> > > +{
> > > + struct fwnode_handle *node;
> > > + unsigned int count = 0;
> > > + void *ret;
> > > + int i;
>
> unsigned int, please.
>
Sounds good.
> > > +
> > > + for (i = 0; ; i++) {
> > > + if (count >= matches_len)
> > > + return count;
> > > +
> > > + node = fwnode_find_reference(fwnode, con_id, i);
> > > + if (IS_ERR(node))
> > > + break;
> > > +
> > > + ret = match(node, NULL, data);
> > > + fwnode_handle_put(node);
> > > +
> > > + if (ret)
> > > + matches[count++] = ret;
> > > + }
> > > +
> > > + return count;
> > > +}
> > > +
> > > /**
> > > * fwnode_connection_find_match - Find connection from a device node
> > > * @fwnode: Device node with the connection
> > > @@ -1229,3 +1288,38 @@ void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
> > > return fwnode_devcon_match(fwnode, con_id, data, match);
> > > }
> > > EXPORT_SYMBOL_GPL(fwnode_connection_find_match);
> > > +
> > > +/**
> > > + * fwnode_connection_find_matches - Find connections from a device node
> > > + * @fwnode: Device node with the connection
> > > + * @con_id: Identifier for the connection
> > > + * @data: Data for the match function
> > > + * @match: Function to check and convert the connection description
> > > + * @matches: Array of pointers to fill with matches
> > > + * @matches_len: Length of @matches
> > > + *
> > > + * Find up to @matches_len connections with unique identifier @con_id between
> > > + * @fwnode and other device nodes. @match will be used to convert the
> > > + * connection description to data the caller is expecting to be returned
> > > + * through the @matches array.
>
> If the caller allocates the matches array, how does it know how large it
> should be? Is there a need to provide a way to count the matches before
> writing them to an array? Most similar functions do that by just setting the
> array (matches) to NULL.
>
This is a very relevant comment and I did look for ways to handle this
as I came up with the patch.
I think the typical mechanism would be to allow @matches to be NULL, in
which case we iterate over objects and return the number of matches, so
that the caller can allocate an appropriately sized array and call the
API again.
But the "match" function simply returns a pointer to something and
looking at the example of the typec_{mux,switch} this pointer points to
a member of an object which has a struct device which is refcounted.
As such, we can't simply discard the returned object. We have to pass it
back to the caller, whom knows what "match" did and is able to reverse
that.
I looked at changing the callback and I looked at using krealloc() to
grow an array dynamically.
But looking at the use case in mind; finding entities that might need to
react to a USB Type-C event I have a need for 2 matches, and 3 seems
plausible. Beyond that the largest of_graph I have ever dealt with has 6
endpoints.
While it isn't relevant to use this API for my 6-endpoint case, it would
result in @matches having to be 48 bytes of pointers. And once the call
returns, the actual number of pointers needed is known and the long-term
storage can be re-allocated as necessary based on the return value.
As such, I dropped the idea of making something fancier and more
dynamic, for the sake of simplicity. Perhaps I'm missing some cool use
case where this is infeasible?
Regards,
Bjorn
> > > + *
> > > + * Return: Number of matches resolved, of negative errno.
> > > + */
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches, unsigned int matches_len)
> > > +{
> > > + unsigned int count;
> > > +
> > > + if (!fwnode || !match || !matches)
> > > + return -EINVAL;
> > > +
> > > + count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> > > + matches, matches_len);
> > > +
> > > + return count + fwnode_devcon_matches(fwnode, con_id, data, match,
> > > + matches + count,
> > > + matches_len - count);
> > > +}
> > > +EXPORT_SYMBOL_GPL(fwnode_connection_find_matches);
> > > diff --git a/include/linux/property.h b/include/linux/property.h
> > > index 16f736c698a2..59484ccb260e 100644
> > > --- a/include/linux/property.h
> > > +++ b/include/linux/property.h
> > > @@ -444,6 +444,11 @@ static inline void *device_connection_find_match(struct device *dev,
> > > return fwnode_connection_find_match(dev_fwnode(dev), con_id, data, match);
> > > }
> > >
> > > +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> > > + const char *con_id, void *data,
> > > + devcon_match_fn_t match,
> > > + void **matches, unsigned int matches_len);
> > > +
> > > /* -------------------------------------------------------------------------- */
> > > /* Software fwnode support - when HW description is incomplete or missing */
> > >
>
> --
> Kind regards,
>
> Sakari Ailus
^ permalink raw reply
* Re: mdadm regression tests fail
From: Bruce Dubbs @ 2022-01-05 20:42 UTC (permalink / raw)
To: Wols Lists, Randy Dunlap, linux-raid; +Cc: Douglas R. Reno, Pierre Labastie
In-Reply-To: <96d9e6d4-16e5-6bfe-fc5a-7d0dfbaeadf0@youngman.org.uk>
My point is that many of the tests fail. It's not that someone should use the
superblock v0.9. That's only an example. The test should be removed or marked
"Expected FAIL" or similar. Our users run the tests as a confidence check that the
build is successful. They are generally not trying to debug the package.
I can certainly say that the tests are broken and leave it at that. If it were only
a couple of tests that fail, we generally say something like testA and testG are
known to fail, but in this case fully half of the tests fail.
I would like to know what the maintainers think of the regression tests. Are they
maintained? Should they all pass? For our users there are far too many tests to run
them individually.
-- Bruce
On 1/5/22 11:44 AM, Wols Lists wrote:
> Bear in mind raid superblock v0.9 is deprecated as in "if it breaks it won't be fixed
> for you".
>
> So I would skip this test, and if you're mentioning raid in the handbook, tell people
> they need to use one of the v1.x formats.
>
> (NB - you can always point them at the linux raid wiki.)
>
> Cheers,
> Wol
>
> On 05/01/2022 17:12, Randy Dunlap wrote:
>> Hi.
>> [adding linux-raid mailing list]
>>
>>
>> On 1/4/22 10:55, Bruce Dubbs wrote:
>>> I am trying to document the mdadm-4.2 installation procedures for our book,
>>> https://www.linuxfromscratch.org/blfs/view/svn/postlfs/mdadm.html
>>>
>>> For testing, I am doing a simple:
>>>
>>> make
>>> sudo ./test --keep-going --logdir=test-logs --save-logs
>>>
>>> But I get failures for about half the tests.
>>>
>>> Digging in a bit I just ran:
>>>
>>> sudo ./test --tests=00raid0 --logdir=test-logs
>>>
>>> This is the first test that fails. With some hacking, it appears that the first
>>> portion of this test that fails is:
>>>
>>> mdadm -CR $md0 -e0.90 -l0 -n4 $dev0 $dev1 $dev2 $dev3
>>>
>>> This resolves to
>>>
>>> mdadm -CR /dev/md0 -e0.90 -l0 -n4 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
>>>
>>> There is not a lot of error output in the test, so I manually ran:
>>>
>>> dd if=/dev/zero of=/tmp/mdtest0 count=20000 bs=1K
>>> losetup /dev/loop0 /tmp/mdtest0
>>>
>>> For /dev/loop[0123]
>>>
>>> Then I ran
>>>
>>> mdadm -CR /dev/md0 -e0.90 -l0 -n4 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
>>> mdadm: 0.90 metadata does not support layouts for RAID0
>>>
>>> My question is whether the regression tests in the tarball are valid for mdadm-4.2?
>>>
>>> -- Bruce Dubbs
>>> linuxfromscratch.org
>>>
>>> Note: The kernel is version 5.15.12.
>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.