Bug 242689

Summary:	sys.geom.class.multipath.failloop.failloop fails due to too many CTF entries
Product:	Base System	Reporter:	Li-Wen Hsu <lwhsu>
Component:	tests	Assignee:	Mark Johnston <markj>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	asomers, imp
Priority:	---	Flags:	lwhsu: mfc-stable12? lwhsu: mfc-stable11?
Version:	CURRENT
Hardware:	i386
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232675

Description Li-Wen Hsu freebsd_committer

2019-12-17 18:45:37 UTC

https://ci.freebsd.org/job/FreeBSD-head-i386-test/7812/testReport/junit/sys.geom.class.multipath/failloop/failloop/
https://ci.freebsd.org/job/FreeBSD-head-i386-test/7812/changes

Reproduce these by hand:

root@:/usr/tests/sys/geom/class/multipath # mdconfig -a -t swap -s 1M
md0
root@:/usr/tests/sys/geom/class/multipath # mdconfig -a -t swap -s 1M
md1
root@:/usr/tests/sys/geom/class/multipath # gnop create /dev/md0
GEOM_NOP: Device md0.nop created.
root@:/usr/tests/sys/geom/class/multipath # gnop create /dev/md1
GEOM_NOP: Device md1.nop created.
root@:/usr/tests/sys/geom/class/multipath # gmultipath create gm md0.nop md1.nop
GEOM_MULTIPATH: gm created
GEOM_MULTIPATH: md0.nop added to gm
GEOM_MULTIPATH: md0.nop is now active path in gm
GEOM_MULTIPATH: md1.nop added to gm
root@:/usr/tests/sys/geom/class/multipath # sysctl kern.geom.notaste=1
kern.geom.notaste: 0 -> 1
root@:/usr/tests/sys/geom/class/multipath # gnop configure -r 100 -w 100 md0.nop
root@:/usr/tests/sys/geom/class/multipath # gnop configure -r 100 -w 100 md1.nop
root@:/usr/tests/sys/geom/class/multipath # dtrace -o restore_count -i 'geom:multipath:config:restore {@restore = count()}' -c "dd if=/dev/zero of=/dev/multipath/gm bs=4096 count=1"
dtrace: invalid probe specifier geom:multipath:config:restore {@restore = count()}: "/usr/lib/dtrace/psinfo.d", line 39: failed to copy type of 'pr_uid': Type information is in parent and unavailable
GEOM_MULTIPATH: Error 5, md0.nop in gm marked FAIL
GEOM_MULTIPATH: md1.nop is now active path in gm
GEOM_MULTIPATH: Error 5, md1.nop in gm marked FAIL
GEOM_MULTIPATH: all paths in gm were marked FAIL, restore md0.nop
GEOM_MULTIPATH: md0.nop is now active path in gm

VM image (bad): https://artifact.ci.freebsd.org/snapshot/head/r355824/i386/i386/disk-test.img.xz
VM image (good): https://artifact.ci.freebsd.org/snapshot/head/r355820/i386/i386/disk-test.img.xz

Comment 1 Li-Wen Hsu freebsd_committer

2019-12-17 18:48:33 UTC

imp, asomers: could you help check this? All these changes are looking innocent to me, but all the following test failed.

Comment 2 commit-hook freebsd_committer

2019-12-17 19:01:48 UTC

A commit references this bug:

Author: lwhsu
Date: Tue Dec 17 19:01:10 UTC 2019
New revision: 355861
URL: https://svnweb.freebsd.org/changeset/base/355861

Log:
  Temporarily skip failing sys.geom.class.multipath.failloop.failloop on i386 CI

  PR:		242689
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/tests/sys/geom/class/multipath/failloop.sh

Comment 3 Alan Somers freebsd_committer

2019-12-18 04:41:48 UTC

I'll investigate.  I agree that none of the changes look relevant.

Comment 4 Alan Somers freebsd_committer

2019-12-19 04:00:48 UTC

This turns out not to be a gmultipath problem at all, but a dtrace problem.  dtrace apparently fails if the kernel contains > 2^15 CTF entries.  For some reason, the i386 CI test image contains 35,538.  The only short-term solution would be to decrease the amount of stuff in the CI test image to reduce the CTF symbol count.  Long-term solutions are under discussion in bug 232675.

# ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}'
35538

*** This bug has been marked as a duplicate of bug 232675 ***

Comment 5 Li-Wen Hsu freebsd_committer

2019-12-19 11:49:26 UTC

I'll check what we can do for this test case. Reopen for tracking until it get reenabled.

Comment 6 commit-hook freebsd_committer

2020-01-07 15:59:58 UTC

A commit references this bug:

Author: markj
Date: Tue Jan  7 15:59:32 UTC 2020
New revision: 356443
URL: https://svnweb.freebsd.org/changeset/base/356443

Log:
  Define a unified pmap structure for i386.

  The overloading of struct pmap for PAE and non-PAE pmaps results in
  three distinct layouts for the structure, which is embedded in
  struct vmspace.  This causes a large number of duplicate structure
  definitions in the i386 kernel's CTF type graph.

  Since most pmap fields are the same in the two pmaps, simply provide
  side-by-side variants of the fields that are distinct, using fixed-size
  types.

  PR:		242689
  Reviewed by:	kib
  MFC after:	1 week
  Sponsored by:	The FreeBSD Foundation
  Differential Revision:	https://reviews.freebsd.org/D22896

Changes:
  head/sys/i386/i386/pmap.c
  head/sys/i386/i386/pmap_nopae.c
  head/sys/i386/i386/pmap_pae.c
  head/sys/i386/include/pmap.h

Comment 7 commit-hook freebsd_committer

2020-01-07 17:50:12 UTC

A commit references this bug:

Author: lwhsu
Date: Tue Jan  7 17:49:50 UTC 2020
New revision: 356458
URL: https://svnweb.freebsd.org/changeset/base/356458

Log:
  Revert r355861 because the issue has been fixed in r356443

  PR:		242689
  Notified by:	markj
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/tests/sys/geom/class/multipath/failloop.sh

Comment 8 Mark Johnston freebsd_committer

2020-01-14 02:47:32 UTC

There is nothing to MFC after all, stable/12 does not have the dual i386 pmap implementation that triggered this problem.