FreeBSD CI Weekly Report 2019-10-13

2019-10-16 Thread Li-Wen Hsu
(Please send the followup to freebsd-testing@ and note Reply-To is set.)

FreeBSD CI Weekly Report 2019-10-13
===

Here is a summary of the FreeBSD Continuous Integration results for the period
from 2019-10-07 to 2019-10-13.

During this period, we have:

* 2217 builds (91.1% (-8.3) passed, 8.9% (+8.3) failed) of buildworld and
  buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6,
  armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64,
  sparc64 architectures for head, stable/12, stable/11 branches.
* 283 test runs (81.3% (-0.4) passed, 8.5% (-9.8) unstable, 10.2% (+10.2)
  exception) were executed on amd64, i386, riscv64 architectures for head,
  stable/12, stable/11 branches.
* 30 doc builds (100% passed)

Test case status (on 2019-10-13 23:59):
| Branch/Architecture | Total | Pass  | Fail   | Skipped  |
| --- | - | - | -- |  |
| head/amd64  | 7590 (+1) | 7527 (+1) | 0 (0)  | 63 (0)   |
| head/i386   | 7588 (+1) | 7516 (+1) | 0 (0)  | 72 (0)   |
| 12-STABLE/amd64 | 7482 (0)  | 7438 (-3) | 0 (0)  | 44 (+3)  |
| 12-STABLE/i386  | 7480 (0)  | 7432 (0)  | 0 (0)  | 48 (0)   |
| 11-STABLE/amd64 | 6849 (0)  | 6808 (0)  | 0 (0)  | 41 (0)   |
| 11-STABLE/i386  | 6847 (0)  | 6770 (0)  | 34 (0) | 43 (0)   |

(The statistics from experimental jobs are omitted)

If any of the issues found by CI are in your area of interest or expertise
please investigate the PRs listed below.

The latest web version of this report is available at
https://hackmd.io/@FreeBSD-CI/report-20191013 and archive is available at
https://hackmd.io/@FreeBSD-CI/, any help is welcome.

## News

* [FCP 20190401-ci_policy: CI 
policy](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md)
  is in "feedback" state, please check and provide comments on -fcp@ and 
-hackers@ mailing lists.

* A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes 
  how to reproduce and debug the failing cases. It is welcomed to add more
  contents.

## Failing Tests

* https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/
* local.kyua.* (31 cases)
* local.lutok.* (3 cases)

## Failing and Flaky Tests (from experimental jobs)

* https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
* cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d
* https://bugs.freebsd.org/237641

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
* There are ~18 failing and ~97 skipped cases, including flakey ones, see
  
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
 for more details

## Disabled Tests

* sys.fs.tmpfs.mount_test.large
  https://bugs.freebsd.org/212862
* sys.fs.tmpfs.link_test.kqueue
  https://bugs.freebsd.org/213662
* sys.kqueue.libkqueue.kqueue_test.main
  https://bugs.freebsd.org/233586
* sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop
  https://bugs.freebsd.org/220841
* lib.libc.regex.exhaust_test.regcomp_too_big (i386 only)
  https://bugs.freebsd.org/237450
* sys.netinet.socket_afinet.socket_afinet_bind_zero (new)
  https://bugs.freebsd.org/238781
* sys.netpfil.pf.names.names
* sys.netpfil.pf.synproxy.synproxy
  https://bugs.freebsd.org/238870
* sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger 
  https://bugs.freebsd.org/239292
* sys.netpfil.pf.forward.v4 (i386 only)
* sys.netpfil.pf.forward.v6 (i386 only)
* sys.netpfil.pf.set_tos.v4 (i386 only)
  https://bugs.freebsd.org/239380
* sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger 
  https://bugs.freebsd.org/239397
* sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger
  https://bugs.freebsd.org/239399
* sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger
  https://bugs.freebsd.org/239425
* lib.libc.gen.getmntinfo_test.getmntinfo_test
  https://bugs.freebsd.org/240049
* sys.sys.qmath_test.qdivq_s64q
  https://bugs.freebsd.org/240219
* sys.kern.ptrace_test.ptrace__getppid
  https://bugs.freebsd.org/240510
* lib.libc.sys.stat_test.stat_socket
  https://bugs.freebsd.org/240621
* sys.netpfil.common.tos.pf_tos (i386 only)
  https://bugs.freebsd.org/240086
* lib.libarchive.functional_test.test_write_filter_zstd
  https://bugs.freebsd.org/240683

## Issues

### Cause build fails
* https://bugs.freebsd.org/233735
  Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: 
machine/endian.h: No such file or directory
* https://bugs.freebsd.org/233769
  Possible build race: ld: error: unable to find library -lgcc_s

### Cause kernel panics
* https://bugs.freebsd.org/238870
  sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic
  Patch exists:
* https://reviews.freebsd.org/D20868
* https://reviews.freebsd.org/D20869

### Open
* https://bugs.freebsd.org/237403
  Tests in sys/opencrypto should be converted to Python3
* 

Re: DRM-current-kmod is still a problem at r353339

2019-10-16 Thread Neel Chauhan

While drm-current-kmod worked for a little while, it broke with r353645.

https://i.imgur.com/Q5nYZf2.jpg

I'm using the same HP Spectre that I used earlier (where it worked and 
where it panicked).


-Neel

===

https://www.neelc.org/

On 2019-10-13 10:37, Mateusz Guzik wrote:

On 10/13/19, Evilham  wrote:

Hello,

I somehow had managed to mess up my build system and only
yesterday got it back to compiling properly.



So to be clear, there is an unrelated bug where it seems the module can
decide to abort loading and then it crashes in pseudofs. This can 
happen

if there is a mismatch between the kernel and the module itself.



On ds., oct. 12 2019, Mateusz Guzik wrote:


Try this:

https://people.freebsd.org/~mjg/pmap-fict-invl.diff



I tested this patch on top of r353449 and a panic is still
ocurring when the drm-kmod modules are loaded.

This is on a Lenovo A485 Laptop, which is an AMD Ryzen processor
and a Radeon Vega graphics.
My last known working revision is r352987.


Here are bits of the core dump, I hope they are useful, if more
information is needed, please don't hesitate to ask.
BTW: I usually compile GENERIC-NODEBUG, if that results in the
dump being useless (sadly I can't tell), I can disable all the
performance goodies and compile GENERIC :-).
--
Evilham


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xf8
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80b1be61
stack pointer   = 0x28:0xfe00dd81ccc0
frame pointer   = 0x28:0xfe00dd81ccf0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 24022 (kldload)
trap number = 12
panic: page fault
cpuid = 2
time = 1570970502
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00dd81c920
vpanic() at vpanic+0x17e/frame 0xfe00dd81c980
panic() at panic+0x43/frame 0xfe00dd81c9e0
trap_pfault() at trap_pfault/frame 0xfe00dd81ca50
trap_pfault() at trap_pfault+0x4f/frame 0xfe00dd81cac0
trap() at trap+0x288/frame 0xfe00dd81cbf0
calltrap() at calltrap+0x8/frame 0xfe00dd81cbf0
--- trap 0xc, rip = 0x80b1be61, rsp = 0xfe00dd81ccc0,
rbp = 0xfe00dd81ccf0 ---
pfs_destroy() at pfs_destroy+0x11/frame 0xfe00dd81ccf0
pfs_uninit() at pfs_uninit+0x16/frame 0xfe00dd81cd10
vfs_modevent() at vfs_modevent+0x474/frame 0xfe00dd81cd50
module_register_init() at module_register_init+0xa4/frame
0xfe00dd81cd80
linker_load_module() at linker_load_module+0xb49/frame
0xfe00dd81d0a0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d0f0
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d1b0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d4d0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d520
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d5e0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d900
kern_kldload() at kern_kldload+0xbd/frame 0xfe00dd81d950
sys_kldload() at sys_kldload+0x5b/frame 0xfe00dd81d980
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe00dd81dab0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe00dd81dab0
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d1cda,
rsp = 0x7fffd748, rbp = 0x7fffdcc0 ---
KDB: enter: panic


__curthread () at /freebsd/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0  __curthread () at
/freebsd/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=0) at
 /freebsd/src/sys/kern/kern_shutdown.c:392
#2  0x80496a7a in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=)
at /freebsd/src/sys/ddb/db_command.c:575
#3  0x8049683c in db_command (last_cmdp=,
cmd_table=, dopager=1)
at /freebsd/src/sys/ddb/db_command.c:482
#4  0x804965ad in db_command_loop ()
at /freebsd/src/sys/ddb/db_command.c:535
#5  0x80499858 in db_trap (type=,
 code=)
at /freebsd/src/sys/ddb/db_main.c:252
#6  0x80c322a7 in kdb_trap (type=3, code=0, tf=)
at /freebsd/src/sys/kern/subr_kdb.c:692
#7  0x8105d925 in trap (frame=0xfe00dd81c850)
at /freebsd/src/sys/amd64/amd64/trap.c:585
#8  
#9  kdb_enter (why=0x811dee7e "panic", msg=)
at /freebsd/src/sys/kern/subr_kdb.c:479
#10 0x80be377a in vpanic (fmt=,
 ap=)
at /freebsd/src/sys/kern/kern_shutdown.c:897
#11 0x80be35d3 in panic (
fmt=0x818e4c18 
"\357\327\037\201\377\377\377\377") at
/freebsd/src/sys/kern/kern_shutdown.c:835
#12 0x8105ddb0 in trap_fatal (frame=0xfe00dd81cc00,
 eva=248)
at