- Package:
- src:xgboost
- Source:
- src:xgboost
- Submitter:
- Paul Gevers
- Date:
- 2026-08-22 17:47:01 UTC
- Severity:
- normal
Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly times out after 2:47h on amd64 while some runs are quick and everything in between. On other architectures the tests seem to only take minutes. I'm wondering if the test is extremely sensitive to the load of the system and/or the available memory and cores. Our amd64 worker has 64 cores and 256 GB RAM. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul
Hi, Thank you for raising this to attention. I tried autopkgtest on some of my machines, and they all finished really fast (~1min), including: - Intel Core i9 14900K - Intel Xeon E5-2680v4 - Intel Xeon Platinum 8358 - AMD EPYC 7742 / 7763 I’m not quite sure why it would be ridiculously slow on debci machines. Is it possible there are major ISA differences (e.g. AVX disabled), or something like cpu / memory over-subscription? Thanks, Shengqi Chen
Hi,
Does this help?
root@ci-worker13:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 43 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Vendor ID: AuthenticAMD
Model name: AMD EPYC 7502P 32-Core Processor
CPU family: 23
Model: 49
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 1
Stepping: 0
BogoMIPS: 4990.49
Flags: fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse36 clflus
h mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm constant_t
sc rep_good nopl xtopology nonstop_tsc
cpuid extd_apicid aperfmperf rapl pni p
clmulqdq monitor ssse3 fma cx16 sse4_1
sse4_2 x2apic movbe popcnt aes xsave av
x f16c rdrand lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt tce
topoext perfctr_core perfctr_nb bpext pe
rfctr_llc mwaitx cpb cat_l3 cdp_l3
hw_pstate ssbd mba ibrs ibpb stibp vmmcall
fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a
rdseed adx smap clflushopt clwb sha_ni
xsaveopt xsavec xgetbv1 xsaves cqm_llc
cqm_occup_llc cqm_mbm_total cqm_mbm_loc
al clzero irperf xsaveerptr rdpru wbnoinvd
amd_ppin arat npt lbrv svm_lock nri
p_save tsc_scale vmcb_clean flushbyasid
decodeassists pausefilter pfthreshold
avic v_vmsave_vmload vgif v_spec_ctrl umip
rdpid overflow_recov succor smca se
v sev_es
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 1 MiB (32 instances)
L1i: 1 MiB (32 instances)
L2: 16 MiB (32 instances)
L3: 128 MiB (8 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-63
Vulnerabilities:
Gather data sampling: Not affected
Indirect target selection: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Mitigation; untrained return thunk; SMT
enabled with STIBP protection
Spec rstack overflow: Mitigation; Safe RET
Spec store bypass: Mitigation; Speculative Store Bypass
disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and
__user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional;
STIBP always-on; RSB filling; PBRSB-
eIBRS Not affected; BHI Not affected
Srbds: Not affected
Tsa: Not affected
Tsx async abort: Not affected
Vmscape: Mitigation; IBPB before exit to userspace
This problem no longer exists in 3.3.0-1.