* [LTP] Holidays and LTP release @ 2020-12-17 12:18 Cyril Hrubis 2021-01-06 12:19 ` Cyril Hrubis 0 siblings, 1 reply; 22+ messages in thread From: Cyril Hrubis @ 2020-12-17 12:18 UTC (permalink / raw) To: ltp Hi! As usuall I will start my Christmas vacation tomorrow and then return back to work after the New Year. And as usually we are due to produce a release somewhere at the end of January, that means that we should have our usuall git freeze and pre-relase testing ideally somewhere at the end of the first week in January. I've tried to review and merge as many patches as possible during this week, but if there is something that should definitly get in before the release, just let me know and I will have a look. And lastly but not least Merry Christmas and Happy New Year to everyone who celbrates these. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2020-12-17 12:18 [LTP] Holidays and LTP release Cyril Hrubis @ 2021-01-06 12:19 ` Cyril Hrubis 2021-01-07 11:51 ` Cyril Hrubis ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-06 12:19 UTC (permalink / raw) To: ltp Hi! As you may noticed I'm back and I'm trying to review anything that should be considered for the release. Please let me know if there is anything I should look into. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-06 12:19 ` Cyril Hrubis @ 2021-01-07 11:51 ` Cyril Hrubis 2021-01-08 1:23 ` Yang Xu 2021-01-11 14:38 ` Cyril Hrubis 2021-01-13 8:57 ` =?unknown-8bit?q?K=C3=B6ry?= Maincent 2021-01-14 9:17 ` Martin Doucha 2 siblings, 2 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-07 11:51 UTC (permalink / raw) To: ltp Hi! Is there anything that should be considered for the release? If not I would like to freeze the git at the end of the week and start the pre-relase testing on Monday next week. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-07 11:51 ` Cyril Hrubis @ 2021-01-08 1:23 ` Yang Xu 2021-01-08 13:28 ` Cyril Hrubis 2021-01-11 14:38 ` Cyril Hrubis 1 sibling, 1 reply; 22+ messages in thread From: Yang Xu @ 2021-01-08 1:23 UTC (permalink / raw) To: ltp Hi Cyril > Hi! > Is there anything that should be considered for the release? We can apply patch[1] disables the test(ioctl_loop05) on overlay so that it's fixed for next release. Also, please see patch[2] for cpu_inherit fix. [1]https://patchwork.ozlabs.org/project/ltp/patch/20201215155650.6496-1-radoslav.kolev@suse.com/ [2]https://patchwork.ozlabs.org/project/ltp/patch/1606701966-1596-1-git-send-email-xuyang2018.jy@cn.fujitsu.com/ Best Regards Yang Xu > > If not I would like to freeze the git at the end of the week and start > the pre-relase testing on Monday next week. > ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-08 1:23 ` Yang Xu @ 2021-01-08 13:28 ` Cyril Hrubis 0 siblings, 0 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-08 13:28 UTC (permalink / raw) To: ltp Hi! > We can apply patch[1] disables the test(ioctl_loop05) on overlay so that > it's fixed for next release. Agree, will you push it or should I do so? > Also, please see patch[2] for cpu_inherit fix. I looked at that one and acked it. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-07 11:51 ` Cyril Hrubis 2021-01-08 1:23 ` Yang Xu @ 2021-01-11 14:38 ` Cyril Hrubis 2021-01-12 10:29 ` Petr Vorel 1 sibling, 1 reply; 22+ messages in thread From: Cyril Hrubis @ 2021-01-11 14:38 UTC (permalink / raw) To: ltp Hi! As I anounced last week please consider git frozen for anything but important fixes now. Also if you haven't done so yet, please test latest git head now and report any problems you find. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-11 14:38 ` Cyril Hrubis @ 2021-01-12 10:29 ` Petr Vorel 0 siblings, 0 replies; 22+ messages in thread From: Petr Vorel @ 2021-01-12 10:29 UTC (permalink / raw) To: ltp Hi Cyril, > Hi! > As I anounced last week please consider git frozen for anything but > important fixes now. I was thinking about speedup if-mtu-change.sh [1], but unless Alexey ack that it might be better to wait after the release. I planned to merge two rewrites to new API (v2 get_mempolicy [2] and v3 multicast packed flood [3]), which are ready, but as there is a git freeze it can wait after the release. I'd also like to add some docs to ima_tpm.sh setup when running with ima_policy=tcb on real HW, if I figure out what's needed. I might have look into sigwaitinfo01 problems on MUSL. There is a patch which needs to be rebased [4] (tests and libsigwait were rewritten to new API). But simply remove all testcases because they does not work on MUSL is probably no-go. I guess the problem is with using (void *)1 in in various sigwaitinfo tests in test_bad_address{,2,3}() (libs/libltpsigwait/sigwait.c). Maybe use tst_get_bad_addr(NULL) here? > Also if you haven't done so yet, please test latest git head now and > report any problems you find. Going to. Kind regards, Petr [1] https://patchwork.ozlabs.org/project/ltp/patch/20210107120247.31465-1-pvorel@suse.cz/ [2] https://patchwork.ozlabs.org/project/ltp/patch/20210106181735.1588-1-pvorel@suse.cz/ [3] https://patchwork.ozlabs.org/project/ltp/list/?series=216562&state=* [4] https://patchwork.ozlabs.org/project/ltp/patch/20200529014448.3815022-1-raj.khem@gmail.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-06 12:19 ` Cyril Hrubis 2021-01-07 11:51 ` Cyril Hrubis @ 2021-01-13 8:57 ` =?unknown-8bit?q?K=C3=B6ry?= Maincent 2021-01-14 11:12 ` Naresh Kamboju 2021-01-14 9:17 ` Martin Doucha 2 siblings, 1 reply; 22+ messages in thread From: =?unknown-8bit?q?K=C3=B6ry?= Maincent @ 2021-01-13 8:57 UTC (permalink / raw) To: ltp Hello Cyril, On Wed, 6 Jan 2021 13:19:39 +0100 Cyril Hrubis <chrubis@suse.cz> wrote: > Hi! > As you may noticed I'm back and I'm trying to review anything that > should be considered for the release. > > Please let me know if there is anything I should look into. I don't know if this can be useful before the release but I have made a table of the result of my LTP test. The test was run on an iMX8 Quad with OpenEmbedded distribution composed of Busybox and Dropbear. https://drive.google.com/drive/folders/1fyBOCjwc_3JiJ3MmMZcWh-m_VVZIDlxv?usp=sharing Regards, K?ry ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-13 8:57 ` =?unknown-8bit?q?K=C3=B6ry?= Maincent @ 2021-01-14 11:12 ` Naresh Kamboju 2021-01-14 14:14 ` Martin Doucha 2021-01-14 14:36 ` Cyril Hrubis 0 siblings, 2 replies; 22+ messages in thread From: Naresh Kamboju @ 2021-01-14 11:12 UTC (permalink / raw) To: ltp On Wed, 13 Jan 2021 at 14:27, K?ry Maincent <kory.maincent@bootlin.com> wrote: > > Hello Cyril, > > On Wed, 6 Jan 2021 13:19:39 +0100 > Cyril Hrubis <chrubis@suse.cz> wrote: > > > Hi! > > As you may noticed I'm back and I'm trying to review anything that > > should be considered for the release. > > > > Please let me know if there is anything I should look into. > > I don't know if this can be useful before the release but I have made a table of > the result of my LTP test. The test was run on an iMX8 Quad with OpenEmbedded > distribution composed of Busybox and Dropbear. I have a similar problem for semctl09 failed on arm, arm64, i386 and x86_64. semctl09.c:67: TINFO: Test SYS_semc[ 1067.769270] audit: type=1701 audit(1610604534.411:38): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=6275 comm=\"semctl09\" exe=\"/opt/ltp/testcases/bin/semctl09\" sig=11 res=1 tl syscall semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10 semctl09.c:164: TPASS: Counted used = 1 semctl09.c:112: TPASS: semset_cnt = 1 semctl09.c:119: TPASS: sen_cnt = 2 tst_test.c:1313: TBROK: Test killed by SIGSEGV! And on i386, tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s semctl09.c:67: TINFO: Test SYS_semctl syscall semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11 semctl09.c:164: TPASS: Counted used = 1 semctl09.c:112: TPASS: semset_cnt = 1 semctl09.c:119: TPASS: sen_cnt = 2 semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11 semctl09.c:164: TPASS: Counted used = 1 semctl09.c:112: TPASS: semset_cnt = 1 semctl09.c:119: TPASS: sen_cnt = 2 tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s semctl09.c:70: TINFO: Test libc semctl() semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified by the caller to kernel semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified by the caller to kernel only fails on the arm beagleboard-x15 device. accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19) clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards (5): -1610153174499293029 ns clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference between successive readings greater than 5 ms (4): 9 clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between successive readings is reasonable clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference between successive readings greater than 5 ms (2): 9 clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between successive readings is reasonable clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between successive readings is reasonable getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0) gave consistent results tst_test.c:1313: TBROK: Test killed by SIGILL! on x86_64: The ioctl_sg01 test killed and reported failed. tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1 [ 332.383394] ioctl_sg01 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 [ 332.393225] CPU: 0 PID: 14622 Comm: ioctl_sg01 Not tainted 5.10.6 #2 [ 332.399572] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.0b 07/27/2017 [ 332.407080] Call Trace: [ 332.409543] dump_stack+0x7d/0x9f [ 332.412861] dump_header+0x4f/0x1f3 [ 332.416351] oom_kill_process.cold+0xb/0x10 [ 332.420531] out_of_memory+0x1bb/0x4e0 [ 332.424283] __alloc_pages_slowpath.constprop.0+0xc39/0xd00 [ 332.429847] __alloc_pages_nodemask+0x2a9/0x310 [ 332.434379] alloc_pages_current+0x87/0xe0 [ 332.438470] __page_cache_alloc+0x89/0xb0 [ 332.442482] pagecache_get_page+0xe3/0x280 [ 332.446572] filemap_fault+0x5b1/0xc90 [ 332.450316] ? page_add_file_rmap+0x16c/0x1d0 [ 332.454666] ? alloc_set_pte+0xf2/0x670 [ 332.458498] __do_fault+0x3c/0xa0 [ 332.461808] handle_mm_fault+0xf73/0x1610 [ 332.465812] ? finish_task_switch+0x74/0x230 [ 332.470098] do_user_addr_fault+0x1dc/0x3c0 [ 332.474278] exc_page_fault+0x54/0x110 [ 332.478023] ? asm_exc_page_fault+0x8/0x30 [ 332.482112] asm_exc_page_fault+0x1e/0x30 [ 332.486116] RIP: 0033:0x7f7405231130 [ 332.489691] Code: Unable to access opcode bytes at RIP 0x7f7405231106. [ 332.496214] RSP: 002b:00007fff9e9afe28 EFLAGS: 00010202 [ 332.501430] RAX: 00007f7030e69000 RBX: 0000000000000001 RCX: 00007f7403e69000 [ 332.508553] RDX: 0000000000000000 RSI: 0000000001000000 RDI: 00007f7403e69000 [ 332.515677] RBP: 00007f7403e69000 R08: 0000000001000000 R09: 0000000000000000 [ 332.522801] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000001000000 [ 332.529926] R13: 000000000041861a R14: 000000000000003b R15: 0000000000000000 [ 332.537092] Mem-Info: [ 332.539376] active_anon:144 inactive_anon:4026083 isolated_anon:0 [ 332.539376] active_file:63 inactive_file:8 isolated_file:0 [ 332.539376] unevictable:0 dirty:33 writeback:0 [ 332.539376] slab_reclaimable:4320 slab_unreclaimable:6040 [ 332.539376] mapped:136 shmem:6370 pagetables:8672 bounce:0 [ 332.539376] free:34555 free_pcp:20 free_cma:0 [ 332.570972] Node 0 active_anon:576kB inactive_anon:16104332kB active_file:180kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:544kB dirty:132kB writeback:0kB shmem:25480kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB kernel_stack:2400kB all_unreclaimable? yes [ 332.598731] Node 0 DMA free:15868kB min:64kB low:80kB high:96kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15964kB managed:15868kB mlocked:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 332.625036] lowmem_reserve[]: 0 2173 15940 15940 [ 332.629729] Node 0 DMA32 free:64224kB min:9204kB low:11504kB high:13804kB reserved_highatomic:0KB active_anon:0kB inactive_anon:2156620kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:2291100kB managed:2225564kB mlocked:0kB pagetables:4216kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 332.658024] lowmem_reserve[]: 0 0 13766 13766 [ 332.662375] Node 0 Normal free:58128kB min:58312kB low:72888kB high:87464kB reserved_highatomic:0KB active_anon:576kB inactive_anon:13947404kB active_file:744kB inactive_file:0kB unevictable:0kB writepending:76kB present:14417920kB managed:14101104kB mlocked:0kB pagetables:30472kB bounce:0kB free_pcp:16kB local_pcp:0kB free_cma:0kB [ 332.691695] lowmem_reserve[]: 0 0 0 0 [ 332.695361] Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15868kB [ 332.709435] Node 0 DMA32: 2*4kB (UM) 3*8kB (UM) 3*16kB (UM) 2*32kB (UM) 1*64kB (M) 2*128kB (UM) 1*256kB (M) 1*512kB (U) 0*1024kB 1*2048kB (M) 15*4096kB (M) = 64720kB [ 332.724210] Node 0 Normal: 784*4kB (UME) 409*8kB (UME) 183*16kB (UME) 67*32kB (UME) 38*64kB (E) 36*128kB (ME) 28*256kB (ME) 12*512kB (ME) 4*1024kB (E) 1*2048kB (E) 5*4096kB (U) = 58456kB [ 332.740807] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 332.749257] 6513 total pagecache pages [ 332.753001] 0 pages in swap cache [ 332.756338] Swap cache stats: add 0, delete 0, find 0/0 [ 332.761563] Free swap = 0kB [ 332.764441] Total swap = 0kB [ 332.767316] 4181246 pages RAM [ 332.770306] 0 pages HighMem/MovableOnly [ 332.774137] 95612 pages reserved [ 332.777363] Tasks state (memory values in pages): [ 332.782079] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [ 332.790713] [ 333] 0 333 12626 164 114688 0 0 systemd-journal [ 332.799749] [ 348] 0 348 10499 275 114688 0 -1000 systemd-udevd [ 332.808615] [ 372] 993 372 8666 79 114688 0 0 systemd-network [ 332.817652] [ 384] 992 384 9529 77 122880 0 0 systemd-resolve [ 332.826686] [ 387] 996 387 7243 154 106496 0 -900 dbus-daemon [ 332.835375] [ 388] 0 388 2313 71 61440 0 0 crond [ 332.843564] [ 389] 0 389 2112 19 57344 0 0 syslogd [ 332.851904] [ 391] 0 391 3029 783 65536 0 0 haveged [ 332.860250] [ 392] 0 392 81271 490 262144 0 0 NetworkManager [ 332.869229] [ 393] 0 393 2112 20 61440 0 0 klogd [ 332.877402] [ 395] 0 395 8615 107 110592 0 0 systemd-logind [ 332.886353] [ 396] 0 396 1075 22 57344 0 0 acpid [ 332.894525] [ 398] 0 398 34025 158 167936 0 0 thermald [ 332.902956] [ 399] 995 399 9341 81 114688 0 0 avahi-daemon [ 332.911728] [ 409] 995 409 9277 68 106496 0 0 avahi-daemon [ 332.920505] [ 438] 65534 438 3245 38 65536 0 0 dnsmasq [ 332.928870] [ 439] 0 439 3187 33 69632 0 0 agetty [ 332.937130] [ 440] 0 440 14707 108 163840 0 0 login [ 332.945328] [ 441] 0 441 3187 34 69632 0 0 agetty [ 332.953588] [ 444] 998 444 131113 827 241664 0 0 polkitd [ 332.961932] [ 461] 0 461 9532 162 118784 0 0 systemd [ 332.970270] [ 462] 0 462 16166 462 163840 0 0 (sd-pam) [ 332.978719] [ 466] 0 466 4538 104 77824 0 0 sh [ 332.986632] [ 471] 0 471 11102 83 135168 0 0 su [ 332.994544] [ 472] 0 472 4538 100 77824 0 0 sh [ 333.002455] [ 517] 0 517 2396 56 61440 0 0 lava-test-runne [ 333.011487] [ 527] 0 527 2396 52 65536 0 0 lava-test-shell [ 333.020525] [ 528] 0 528 2396 55 69632 0 0 sh [ 333.028455] [ 530] 0 530 2495 169 65536 0 0 ltp.sh [ 333.036707] [ 553] 0 553 2495 169 61440 0 0 ltp.sh [ 333.044965] [ 554] 0 554 2495 169 61440 0 0 ltp.sh [ 333.053224] [ 555] 0 555 2495 169 61440 0 0 ltp.sh [ 333.061473] [ 556] 0 556 2561 224 69632 0 0 runltp [ 333.069725] [ 557] 0 557 1072 15 53248 0 0 tee [ 333.077725] [ 623] 0 623 1103 66 61440 0 0 ltp-pan [ 333.086069] [ 14595] 0 14595 3187 34 73728 0 0 agetty [ 333.094347] [ 14621] 0 14621 1198 16 49152 0 0 ioctl_sg01 [ 333.102951] [ 14622] 0 14622 4015311 4014104 32231424 0 0 ioctl_sg01 [ 333.111548] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=ioctl_sg01,pid=14622,uid=0 [ 333.124428] Out of memory: Killed process 14622 (ioctl_sg01) total-vm:16061244kB, anon-rss:16056416kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:31476kB oom_score_adj:0 [ 333.374806] oom_reaper: reaped process 14622 (ioctl_sg01), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB tst_test.c:1308: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 tst_test.c:1309: TBROK: Test killed! (timeout?) ksm03 and ksm03_1 both failed due to, tst_device.c:423: TINFO: No device is mounted at /tmp/cgroup_mem tst_cgroup.c:122: TINFO: Cgroup v2 mount at /tmp/cgroup_mem success tst_cgroup.c:301: TBROK: Failed to close FILE '/tmp/cgroup_mem/cgroup.subtree_control': ENOENT (2) > https://drive.google.com/drive/folders/1fyBOCjwc_3JiJ3MmMZcWh-m_VVZIDlxv?usp=sharing - Naresh ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-14 11:12 ` Naresh Kamboju @ 2021-01-14 14:14 ` Martin Doucha 2021-01-20 9:31 ` Naresh Kamboju 2021-01-14 14:36 ` Cyril Hrubis 1 sibling, 1 reply; 22+ messages in thread From: Martin Doucha @ 2021-01-14 14:14 UTC (permalink / raw) To: ltp On 14. 01. 21 12:12, Naresh Kamboju wrote: > on x86_64: > The ioctl_sg01 test killed and reported failed. > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1 > [ 332.383394] ioctl_sg01 invoked oom-killer: Looks like the safety margin in tst_pollute_memory() is too small. Edit lib/tst_memutils.c and try setting the "safety" variable on line 23 to a higher value. I'd recommend something like MAX(4096 pages, 64MB). -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-14 14:14 ` Martin Doucha @ 2021-01-20 9:31 ` Naresh Kamboju 2021-01-20 10:26 ` Cyril Hrubis 0 siblings, 1 reply; 22+ messages in thread From: Naresh Kamboju @ 2021-01-20 9:31 UTC (permalink / raw) To: ltp On Thu, 14 Jan 2021 at 19:44, Martin Doucha <mdoucha@suse.cz> wrote: > > On 14. 01. 21 12:12, Naresh Kamboju wrote: > > on x86_64: > > The ioctl_sg01 test killed and reported failed. > > > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1 > > [ 332.383394] ioctl_sg01 invoked oom-killer: > > Looks like the safety margin in tst_pollute_memory() is too small. Edit > lib/tst_memutils.c and try setting the "safety" variable on line 23 to a > higher value. I'd recommend something like MAX(4096 pages, 64MB). do you mean something like this ? But this change did not solve the problem (ioctl_sg01) i have reported. diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c index f134d90c9..00bf45e9c 100644 --- a/lib/tst_memutils.c +++ b/lib/tst_memutils.c @@ -20,7 +20,7 @@ void tst_pollute_memory(size_t maxsize, int fillchar) struct sysinfo info; SAFE_SYSINFO(&info); - safety = 4096 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit; + safety = 8192 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit; if (info.freeswap > safety) safety = 0; After the above change the test case ioctl_sg01 fails intermittently when running multiple times. https://lkft.validation.linaro.org/scheduler/job/2170593#L1357 - Naresh ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-20 9:31 ` Naresh Kamboju @ 2021-01-20 10:26 ` Cyril Hrubis 2021-01-20 13:33 ` Cyril Hrubis 0 siblings, 1 reply; 22+ messages in thread From: Cyril Hrubis @ 2021-01-20 10:26 UTC (permalink / raw) To: ltp Hi! > do you mean something like this ? > But this change did not solve the problem (ioctl_sg01) i have reported. > > diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c > index f134d90c9..00bf45e9c 100644 > --- a/lib/tst_memutils.c > +++ b/lib/tst_memutils.c > @@ -20,7 +20,7 @@ void tst_pollute_memory(size_t maxsize, int fillchar) > struct sysinfo info; > > SAFE_SYSINFO(&info); > - safety = 4096 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit; > + safety = 8192 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit; Actually Martin sugessted a different patch that chooses the margin to be the greater of 4096 pages or 64MB, which would effectivelly set the safety to "16384 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit" on most systems. Also I've been playing with a VM and I've been able to reproduce occasional failures with swap turned off and memory_overcommit set to 1 that Martin's patch fixed for me. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-20 10:26 ` Cyril Hrubis @ 2021-01-20 13:33 ` Cyril Hrubis 0 siblings, 0 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-20 13:33 UTC (permalink / raw) To: ltp Hi! > > do you mean something like this ? > > But this change did not solve the problem (ioctl_sg01) i have reported. > > > > diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c > > index f134d90c9..00bf45e9c 100644 > > --- a/lib/tst_memutils.c > > +++ b/lib/tst_memutils.c > > @@ -20,7 +20,7 @@ void tst_pollute_memory(size_t maxsize, int fillchar) > > struct sysinfo info; > > > > SAFE_SYSINFO(&info); > > - safety = 4096 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit; > > + safety = 8192 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit; > > Actually Martin sugessted a different patch that chooses the margin to > be the greater of 4096 pages or 64MB, which would effectivelly set the > safety to "16384 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit" on most > systems. > > Also I've been playing with a VM and I've been able to reproduce > occasional failures with swap turned off and memory_overcommit set to 1 > that Martin's patch fixed for me. And it looks like the patch for tst_memutils.c is the last one that should be taken care of before the release. It would be nice if you could check if that fixes your failures as well. However it made the situation better, at least for me, so I will push it tomorrow morning and proceed with the release. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-14 11:12 ` Naresh Kamboju 2021-01-14 14:14 ` Martin Doucha @ 2021-01-14 14:36 ` Cyril Hrubis 2021-01-15 8:27 ` Naresh Kamboju 1 sibling, 1 reply; 22+ messages in thread From: Cyril Hrubis @ 2021-01-14 14:36 UTC (permalink / raw) To: ltp Hi! > I have a similar problem for semctl09 failed on arm, arm64, i386 and x86_64. > > semctl09.c:67: TINFO: Test SYS_semc[ 1067.769270] audit: type=1701 > audit(1610604534.411:38): auid=4294967295 uid=0 gid=0 ses=4294967295 > pid=6275 comm=\"semctl09\" exe=\"/opt/ltp/testcases/bin/semctl09\" > sig=11 res=1 > tl syscall > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10 > semctl09.c:164: TPASS: Counted used = 1 > semctl09.c:112: TPASS: semset_cnt = 1 > semctl09.c:119: TPASS: sen_cnt = 2 > tst_test.c:1313: TBROK: Test killed by SIGSEGV! There seems to be a part of the log missing here, if it's segfaulting in the libc semctl() there used to be glibc bug for SEM_STAT_ANY which may cause SIGSEGV: https://sourceware.org/bugzilla/show_bug.cgi?id=26637 > And on i386, > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > semctl09.c:67: TINFO: Test SYS_semctl syscall > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11 > semctl09.c:164: TPASS: Counted used = 1 > semctl09.c:112: TPASS: semset_cnt = 1 > semctl09.c:119: TPASS: sen_cnt = 2 > semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user > semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11 > semctl09.c:164: TPASS: Counted used = 1 > semctl09.c:112: TPASS: semset_cnt = 1 > semctl09.c:119: TPASS: sen_cnt = 2 > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > semctl09.c:70: TINFO: Test libc semctl() > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified > by the caller to kernel > semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user > semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified > by the caller to kernel This just says that the glibc bug is present so it's likely that the same bug is causing segfaults on the rest of the architectures. > only fails on the arm beagleboard-x15 device. > > accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19) Looks like muticast groups is not compiled in kernel here. We should handle this and report TCONF instead, however this is not a regression, the test has been like this for three years. > clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards > (5): -1610153174499293029 ns > clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference > between successive readings greater than 5 ms (4): 9 > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between > successive readings is reasonable > clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference > between successive readings greater than 5 ms (2): 9 > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between > successive readings is reasonable > clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between > successive readings is reasonable This shouldn't really happen, what this says is that time jumped 51 years back. That is really absurd. > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0) > gave consistent results > tst_test.c:1313: TBROK: Test killed by SIGILL! Can we have a backtrace here? It's impossible to say what happened here without further debugging. > on x86_64: > The ioctl_sg01 test killed and reported failed. > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1 > [ 332.383394] ioctl_sg01 invoked oom-killer: That's likely due to tst_pollutte_memory(). What are the overcommit settings on that machine? This is probably worth fixing before the release if we manage to figure out the cause. > ksm03 and ksm03_1 both failed due to, > > tst_device.c:423: TINFO: No device is mounted at /tmp/cgroup_mem > tst_cgroup.c:122: TINFO: Cgroup v2 mount at /tmp/cgroup_mem success > tst_cgroup.c:301: TBROK: Failed to close FILE > '/tmp/cgroup_mem/cgroup.subtree_control': ENOENT (2) That is known and reported: https://github.com/linux-test-project/ltp/issues/734 Ritchard is trying to rewrite LTP cgroup library to solved this, it should land in git repository in a month or two. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-14 14:36 ` Cyril Hrubis @ 2021-01-15 8:27 ` Naresh Kamboju 2021-01-15 14:00 ` Cyril Hrubis 0 siblings, 1 reply; 22+ messages in thread From: Naresh Kamboju @ 2021-01-15 8:27 UTC (permalink / raw) To: ltp On Thu, 14 Jan 2021 at 20:05, Cyril Hrubis <chrubis@suse.cz> wrote: > > Hi! > > I have a similar problem for semctl09 failed on arm, arm64, i386 and x86_64. > > > > semctl09.c:67: TINFO: Test SYS_semc[ 1067.769270] audit: type=1701 > > audit(1610604534.411:38): auid=4294967295 uid=0 gid=0 ses=4294967295 > > pid=6275 comm=\"semctl09\" exe=\"/opt/ltp/testcases/bin/semctl09\" > > sig=11 res=1 > > tl syscall > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > > semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10 > > semctl09.c:164: TPASS: Counted used = 1 > > semctl09.c:112: TPASS: semset_cnt = 1 > > semctl09.c:119: TPASS: sen_cnt = 2 > > tst_test.c:1313: TBROK: Test killed by SIGSEGV! > > There seems to be a part of the log missing here, if it's segfaulting in > the libc semctl() there used to be glibc bug for SEM_STAT_ANY which may > cause SIGSEGV: > > https://sourceware.org/bugzilla/show_bug.cgi?id=26637 > > > And on i386, > > > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > > semctl09.c:67: TINFO: Test SYS_semctl syscall > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > > semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11 > > semctl09.c:164: TPASS: Counted used = 1 > > semctl09.c:112: TPASS: semset_cnt = 1 > > semctl09.c:119: TPASS: sen_cnt = 2 > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user > > semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11 > > semctl09.c:164: TPASS: Counted used = 1 > > semctl09.c:112: TPASS: semset_cnt = 1 > > semctl09.c:119: TPASS: sen_cnt = 2 > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > > semctl09.c:70: TINFO: Test libc semctl() > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > > semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified > > by the caller to kernel > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user > > semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified > > by the caller to kernel > > This just says that the glibc bug is present so it's likely that the > same bug is causing segfaults on the rest of the architectures. > > > only fails on the arm beagleboard-x15 device. > > > > accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19) > > Looks like muticast groups is not compiled in kernel here. True. We have not enabled multicast groups. # CONFIG_IP_MULTICAST is not set > > We should handle this and report TCONF instead, however this is not a > regression, the test has been like this for three years. Reporting TCONF would be right here. > > > clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards > > (5): -1610153174499293029 ns > > clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference > > between successive readings greater than 5 ms (4): 9 > > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between > > successive readings is reasonable > > clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference > > between successive readings greater than 5 ms (2): 9 > > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between > > successive readings is reasonable > > clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between > > successive readings is reasonable > > This shouldn't really happen, what this says is that time jumped 51 > years back. That is really absurd. This is always reproduced on arm beagleboard-x15, i386 32-bit qemu_i386 and qemu_arm. clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards (5): -1610599851098100352 ns https://lkft.validation.linaro.org/scheduler/job/2142122#L3885 https://lkft.validation.linaro.org/scheduler/job/2144548#L2534 > > > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0) > > gave consistent results > > tst_test.c:1313: TBROK: Test killed by SIGILL! > > Can we have a backtrace here? It's impossible to say what happened here > without further debugging. I do not have backtrace log for this now. Let me share strace output log in this link, # strace -f ./getrlimit03 https://lkft.validation.linaro.org/scheduler/job/2145166#L2569 > > > on x86_64: > > The ioctl_sg01 test killed and reported failed. > > > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1 > > [ 332.383394] ioctl_sg01 invoked oom-killer: > > That's likely due to tst_pollutte_memory(). > > What are the overcommit settings on that machine? overcommit_memory is 0. After changing overcommit to 2 the test got PASS. > This is probably worth fixing before the release if we manage to figure > out the cause. cat /proc/sys/vm/overcommit_memory 0 cat /proc/sys/vm/overcommit_ratio 50 ./runltp -s ioctl_sg01 --> FAILED echo 2 > /proc/sys/vm/overcommit_memory cat /proc/sys/vm/overcommit_memory 2 ./runltp -s ioctl_sg01 --> PASS Full test run link, https://lkft.validation.linaro.org/scheduler/job/2142340#L8823 - Naresh ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-15 8:27 ` Naresh Kamboju @ 2021-01-15 14:00 ` Cyril Hrubis 2021-01-15 14:27 ` Cyril Hrubis 0 siblings, 1 reply; 22+ messages in thread From: Cyril Hrubis @ 2021-01-15 14:00 UTC (permalink / raw) To: ltp Hi! > > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user > > > semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10 > > > semctl09.c:164: TPASS: Counted used = 1 > > > semctl09.c:112: TPASS: semset_cnt = 1 > > > semctl09.c:119: TPASS: sen_cnt = 2 > > > tst_test.c:1313: TBROK: Test killed by SIGSEGV! > > > > There seems to be a part of the log missing here, if it's segfaulting in > > the libc semctl() there used to be glibc bug for SEM_STAT_ANY which may > > cause SIGSEGV: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26637 And it looks like there is something strange going on here, Martin Doucha is looking into it at the moment. > > > accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19) > > > > Looks like muticast groups is not compiled in kernel here. > > True. > We have not enabled multicast groups. > # CONFIG_IP_MULTICAST is not set > > > > > We should handle this and report TCONF instead, however this is not a > > regression, the test has been like this for three years. > > Reporting TCONF would be right here. Sure, however since this is not a regression let's do that after the release. Feel free to open an issue so that it's not forgotten. > > > clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards > > > (5): -1610153174499293029 ns > > > clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference > > > between successive readings greater than 5 ms (4): 9 > > > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between > > > successive readings is reasonable > > > clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference > > > between successive readings greater than 5 ms (2): 9 > > > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between > > > successive readings is reasonable > > > clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between > > > successive readings is reasonable > > > > This shouldn't really happen, what this says is that time jumped 51 > > years back. That is really absurd. > > This is always reproduced on arm beagleboard-x15, i386 32-bit qemu_i386 > and qemu_arm. > > clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards > (5): -1610599851098100352 ns > > https://lkft.validation.linaro.org/scheduler/job/2142122#L3885 > https://lkft.validation.linaro.org/scheduler/job/2144548#L2534 I've reproduced it here on RPI board, I will have a look. > > > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0) > > > gave consistent results > > > tst_test.c:1313: TBROK: Test killed by SIGILL! > > > > Can we have a backtrace here? It's impossible to say what happened here > > without further debugging. > > I do not have backtrace log for this now. > Let me share strace output log in this link, > # strace -f ./getrlimit03 > https://lkft.validation.linaro.org/scheduler/job/2145166#L2569 Thanks. I've managed to reproduce as well but I have no idea what happens there, it looks like something gets corrupted and the processor attempts to execute invalid code. Maybe we pass wrong size of the rlim structure somewhere and kernel writes over a stack. > > > on x86_64: > > > The ioctl_sg01 test killed and reported failed. > > > > > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s > > > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1 > > > [ 332.383394] ioctl_sg01 invoked oom-killer: > > > > That's likely due to tst_pollutte_memory(). > > > > What are the overcommit settings on that machine? > > overcommit_memory is 0. > After changing overcommit to 2 the test got PASS. > > > This is probably worth fixing before the release if we manage to figure > > out the cause. > > cat /proc/sys/vm/overcommit_memory > 0 > cat /proc/sys/vm/overcommit_ratio > 50 > ./runltp -s ioctl_sg01 --> FAILED > > echo 2 > /proc/sys/vm/overcommit_memory > cat /proc/sys/vm/overcommit_memory > 2 > ./runltp -s ioctl_sg01 --> PASS So it looks like we need better safety margin. Have you tried to increase the safety in the lib/tst_memutils.c as pointed out by Martin? -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-15 14:00 ` Cyril Hrubis @ 2021-01-15 14:27 ` Cyril Hrubis 0 siblings, 0 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-15 14:27 UTC (permalink / raw) To: ltp Hi! > > > > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0) > > > > gave consistent results > > > > tst_test.c:1313: TBROK: Test killed by SIGILL! > > > > > > Can we have a backtrace here? It's impossible to say what happened here > > > without further debugging. > > > > I do not have backtrace log for this now. > > Let me share strace output log in this link, > > # strace -f ./getrlimit03 > > https://lkft.validation.linaro.org/scheduler/job/2145166#L2569 > > Thanks. > > I've managed to reproduce as well but I have no idea what happens there, > it looks like something gets corrupted and the processor attempts to > execute invalid code. > > Maybe we pass wrong size of the rlim structure somewhere and kernel > writes over a stack. This is really strange it looks like glibc has wrong syscall number for getrlimit. On 32bit ARM I do have in /usr/include/asm-generic/unistd.h #define __NR_getrlimit 163 While the getrlimit should be 191. It looks like x86-64 syscall definitions are installed on the system for some strange reason, even the header says that it's for x86-64. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-06 12:19 ` Cyril Hrubis 2021-01-07 11:51 ` Cyril Hrubis 2021-01-13 8:57 ` =?unknown-8bit?q?K=C3=B6ry?= Maincent @ 2021-01-14 9:17 ` Martin Doucha 2021-01-14 10:41 ` Cyril Hrubis 2 siblings, 1 reply; 22+ messages in thread From: Martin Doucha @ 2021-01-14 9:17 UTC (permalink / raw) To: ltp On 06. 01. 21 13:19, Cyril Hrubis wrote: > Hi! > As you may noticed I'm back and I'm trying to review anything that > should be considered for the release. > > Please let me know if there is anything I should look into. Can we add the tst_secureboot_enabled() patchset to the new release? It fixes lockdown detection issues on some kernels and it shouldn't affect anything except the iopl/ioperm syscall tests. https://patchwork.ozlabs.org/project/ltp/list/?series=223859 -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-14 9:17 ` Martin Doucha @ 2021-01-14 10:41 ` Cyril Hrubis 0 siblings, 0 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-14 10:41 UTC (permalink / raw) To: ltp Hi! > Can we add the tst_secureboot_enabled() patchset to the new release? It > fixes lockdown detection issues on some kernels and it shouldn't affect > anything except the iopl/ioperm syscall tests. > https://patchwork.ozlabs.org/project/ltp/list/?series=223859 I will have a look. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release @ 2021-01-14 15:01 gengcixi 0 siblings, 0 replies; 22+ messages in thread From: gengcixi @ 2021-01-14 15:01 UTC (permalink / raw) To: ltp An HTML attachment was scrubbed... URL: <http://lists.linux.it/pipermail/ltp/attachments/20210114/233a150b/attachment.htm> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release @ 2021-01-15 15:08 gengcixi 2021-01-19 10:43 ` Cyril Hrubis 0 siblings, 1 reply; 22+ messages in thread From: gengcixi @ 2021-01-15 15:08 UTC (permalink / raw) To: ltp Hi Cyril: Recently I was forbiden to use gmail. so I hava to use this email to send you message. And I want to know does the rtc02 patchset can merged into the release? If no big errors? please help review and merged?thanks? [1] https://patchwork.ozlabs.org/project/ltp/patch/20210111083711.1715851-2-gengcixi@gmail.com/ [2] https://patchwork.ozlabs.org/project/ltp/patch/20210111083711.1715851-3-gengcixi@gmail.com/ [3] https://patchwork.ozlabs.org/project/ltp/patch/20210111083711.1715851-4-gengcixi@gmail.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* [LTP] Holidays and LTP release 2021-01-15 15:08 gengcixi @ 2021-01-19 10:43 ` Cyril Hrubis 0 siblings, 0 replies; 22+ messages in thread From: Cyril Hrubis @ 2021-01-19 10:43 UTC (permalink / raw) To: ltp Hi! > Recently I was forbiden to use gmail. so I hava to use this email to send you message. > > And I want to know does the rtc02 patchset can merged into the release?? Sorry, it was too late for the current release. I will make sure it gets merged right after the Jan 2021 release is done. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2021-01-20 13:33 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-17 12:18 [LTP] Holidays and LTP release Cyril Hrubis 2021-01-06 12:19 ` Cyril Hrubis 2021-01-07 11:51 ` Cyril Hrubis 2021-01-08 1:23 ` Yang Xu 2021-01-08 13:28 ` Cyril Hrubis 2021-01-11 14:38 ` Cyril Hrubis 2021-01-12 10:29 ` Petr Vorel 2021-01-13 8:57 ` =?unknown-8bit?q?K=C3=B6ry?= Maincent 2021-01-14 11:12 ` Naresh Kamboju 2021-01-14 14:14 ` Martin Doucha 2021-01-20 9:31 ` Naresh Kamboju 2021-01-20 10:26 ` Cyril Hrubis 2021-01-20 13:33 ` Cyril Hrubis 2021-01-14 14:36 ` Cyril Hrubis 2021-01-15 8:27 ` Naresh Kamboju 2021-01-15 14:00 ` Cyril Hrubis 2021-01-15 14:27 ` Cyril Hrubis 2021-01-14 9:17 ` Martin Doucha 2021-01-14 10:41 ` Cyril Hrubis 2021-01-14 15:01 gengcixi 2021-01-15 15:08 gengcixi 2021-01-19 10:43 ` Cyril Hrubis
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.