With n2d-standard-2 and n2d-standard-64 instances only.
Jammy 5.15 gcp / gke kernel does not have this issue.
This is not a regression, I can see this issue way back to sru-20220509, probably exists when we first add N2D instances to the pool.
Tests are not failing, but the return value is 1 due to warning issued (same as bug 2009943)
Output example:
INFO: Test start time: Sat Mar 4 00:54:03 UTC 2023
COMMAND: /opt/ltp/bin/ltp-pan -q -e -S -a 18684 -n 18684 -f /tmp/ltp-3k5fq0dsFO/alltests -l /dev/null -C /dev/null -T /dev/null
LOG File: /dev/null
FAILED COMMAND File: /dev/null
TCONF COMMAND File: /dev/null
Running tests.......
tst_test.c:1526: TINFO: Timeout per run is 0h 00m 30s
tst_device.c:89: TINFO: Found free device 5 '/dev/loop5'
ioctl_loop01.c:85: TPASS: /sys/block/loop5/loop/partscan = 0
ioctl_loop01.c:86: TPASS: /sys/block/loop5/loop/autoclear = 0
ioctl_loop01.c:87: TPASS: /sys/block/loop5/loop/backing_file = '/tmp/ltp-3k5fq0dsFO/ioceZc4p8/test.img'
ioctl_loop01.c:57: TPASS: get expected lo_flag 12
ioctl_loop01.c:59: TPASS: /sys/block/loop5/loop/partscan = 1
ioctl_loop01.c:60: TPASS: /sys/block/loop5/loop/autoclear = 1
ioctl_loop01.c:69: TPASS: access /dev/loop5p1 succeeds
ioctl_loop01.c:75: TPASS: access /sys/block/loop5/loop5p1 succeeds
ioctl_loop01.c:91: TINFO: Test flag can be clear
ioctl_loop01.c:57: TPASS: get expected lo_flag 8
ioctl_loop01.c:59: TPASS: /sys/block/loop5/loop/partscan = 1
ioctl_loop01.c:60: TPASS: /sys/block/loop5/loop/autoclear = 0
ioctl_loop01.c:69: TPASS: access /dev/loop5p1 succeeds
ioctl_loop01.c:75: TPASS: access /sys/block/loop5/loop5p1 succeeds
tst_device.c:255: TWARN: ioctl(/dev/loop5, LOOP_CLR_FD, 0) no ENXIO for too long
Summary:
passed 13
failed 0
broken 0
skipped 0
warnings 1
INFO: ltp-pan reported some tests FAIL
LTP Version: 20220527
INFO: Test end time: Sat Mar 4 00:54:14 UTC 2023
Issue spotted on: 1031.38~ 20.04.1 1029.34~ 20.04.1
* F-gcp 5.4.0-1102.111
* F-gcp-5.15 5.15.0-
* F-gke 5.4.0-1096.103
* F-gke-5.15 5.15.0-
With n2d-standard-2 and n2d-standard-64 instances only.
Jammy 5.15 gcp / gke kernel does not have this issue.
This is not a regression, I can see this issue way back to sru-20220509, probably exists when we first add N2D instances to the pool.
Tests are not failing, but the return value is 1 due to warning issued (same as bug 2009943)
Output example: bin/ltp- pan -q -e -S -a 18684 -n 18684 -f /tmp/ltp- 3k5fq0dsFO/ alltests -l /dev/null -C /dev/null -T /dev/null loop5/loop/ partscan = 0 loop5/loop/ autoclear = 0 loop5/loop/ backing_ file = '/tmp/ltp- 3k5fq0dsFO/ ioceZc4p8/ test.img' loop5/loop/ partscan = 1 loop5/loop/ autoclear = 1 loop5/loop5p1 succeeds loop5/loop/ partscan = 1 loop5/loop/ autoclear = 0 loop5/loop5p1 succeeds
INFO: Test start time: Sat Mar 4 00:54:03 UTC 2023
COMMAND: /opt/ltp/
LOG File: /dev/null
FAILED COMMAND File: /dev/null
TCONF COMMAND File: /dev/null
Running tests.......
tst_test.c:1526: TINFO: Timeout per run is 0h 00m 30s
tst_device.c:89: TINFO: Found free device 5 '/dev/loop5'
ioctl_loop01.c:85: TPASS: /sys/block/
ioctl_loop01.c:86: TPASS: /sys/block/
ioctl_loop01.c:87: TPASS: /sys/block/
ioctl_loop01.c:57: TPASS: get expected lo_flag 12
ioctl_loop01.c:59: TPASS: /sys/block/
ioctl_loop01.c:60: TPASS: /sys/block/
ioctl_loop01.c:69: TPASS: access /dev/loop5p1 succeeds
ioctl_loop01.c:75: TPASS: access /sys/block/
ioctl_loop01.c:91: TINFO: Test flag can be clear
ioctl_loop01.c:57: TPASS: get expected lo_flag 8
ioctl_loop01.c:59: TPASS: /sys/block/
ioctl_loop01.c:60: TPASS: /sys/block/
ioctl_loop01.c:69: TPASS: access /dev/loop5p1 succeeds
ioctl_loop01.c:75: TPASS: access /sys/block/
tst_device.c:255: TWARN: ioctl(/dev/loop5, LOOP_CLR_FD, 0) no ENXIO for too long
Summary:
passed 13
failed 0
broken 0
skipped 0
warnings 1
INFO: ltp-pan reported some tests FAIL
LTP Version: 20220527
INFO: Test end time: Sat Mar 4 00:54:14 UTC 2023
Affected test cases are:
* ioctl_loop01
* ioctl_loop03
* ioctl_loop04
* ioctl_loop05
* ioctl_loop06
* ioctl_loop07
* lchown03
* lchown03_16
* linkat02
* mknod07
* mknodat02
* mount01
* mount04
* mount06