Date: Wed, 15 Apr 2020 17:28:13 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Olivier =?utf-8?q?Cochard-Labb=C3=A9?=" <olivier@freebsd.org> Cc: freebsd-testing@freebsd.org, freebsd-current <freebsd-current@freebsd.org>, Stable <freebsd-stable@freebsd.org>, bofh@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org> Subject: Re: FreeBSD CI Weekly Report 2020-04-12 Message-ID: <CBB8F199-5292-4AC6-90C5-53FADE0F04F7@FreeBSD.org> In-Reply-To: <CA%2Bq%2BTcr-B5dzPKV-DSiDYmcueXX=AFgh6%2Bj0G=-xJYB0XBzBpQ@mail.gmail.com> References: <20200414223710.GB33328@freefall.freebsd.org> <A2DF53A3-FD86-427D-B1EE-508228B0F4CE@FreeBSD.org> <DCC86D9B-ECF3-4393-B1C6-D76D1AE8BAC2@FreeBSD.org> <CA%2Bq%2BTcr-B5dzPKV-DSiDYmcueXX=AFgh6%2Bj0G=-xJYB0XBzBpQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Apr 2020, at 16:49, Olivier Cochard-Labbé wrote: > On Wed, Apr 15, 2020 at 4:10 PM Kristof Provost <kp@freebsd.org> > wrote: > >> >> The problem appears to be that >> /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is >> misparsing >> the `netstat -rnW` output. >> > > Shouldn't scapy use the libxo output of netstat to mitigate this > regression > ? That would likely help, yes. I’m going to leave that decision up to the maintainer, because I’m not going to do the work :) I’m also not sure how “stable” we want the netstat output to be. Best regards, Kristof From owner-freebsd-current@freebsd.org Wed Apr 15 16:33:23 2020 Return-Path: <owner-freebsd-current@freebsd.org> Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5AD452BB831; Wed, 15 Apr 2020 16:33:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 492Sb60plyz447w; Wed, 15 Apr 2020 16:33:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id 03FGXElW047294 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 15 Apr 2020 09:33:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id 03FGXEJ0047293; Wed, 15 Apr 2020 09:33:14 -0700 (PDT) (envelope-from sgk) Date: Wed, 15 Apr 2020 09:33:14 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: panic: sleeping thread. Possibly related to drm and swapping. Message-ID: <20200415163314.GA47279@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 492Sb60plyz447w X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.21 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; IP_SCORE(-0.22)[ip: (0.02), ipnet: 128.95.0.0/16(-0.26), asn: 73(-0.82), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2020 16:33:23 -0000 Just recieved this panic. I am using drm-legacy-kmod-g20200306 on a Dell Latitude D530 laptop. The panic occurred as I was starting libreoffice. Suggestions? mobile dumped core - see /var/crash/vmcore.2 Wed Apr 15 09:22:07 PDT 2020 FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r359179M: Sat Mar 21 13:46:12 PDT 2020 root@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 panic: sleeping thread Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: Sleeping thread (tid 100154, pid 1072) owns a non-sleepable lock KDB: stack backtrace of thread 100154: sched_switch(22209e00,104) at sched_switch+0x173/frame 0x220e04c8 mi_switch(104) at mi_switch+0x13e/frame 0x220e0500 sleepq_switch(2239ecac,ffffe8e0,2239ecac,2239ec2c,220e0574,...) at sleepq_switch+0xe3/frame 0x220e0518 sleepq_timedwait(2239ecac,50) at sleepq_timedwait+0x2a/frame 0x220e0540 _sleep(2239ecac,2239ec2c,50,fcc13e,ffffe8e0,13,0,0,100) at _sleep+0x176/frame 0x220e0574 swap_pager_getpages_locked(1,0,0) at swap_pager_getpages_locked+0x6b5/frame 0x220e05dc swap_pager_getpages(2239ec2c,220e0640,1,0,0) at swap_pager_getpages+0x40/frame 0x220e05fc vm_pager_get_pages(2239ec2c,220e0640,1,0,0,...) at vm_pager_get_pages+0x26/frame 0x220e0624 i915_gem_wire_page(0,220e0677,2239ec2c,0,2239ec3c,...) at i915_gem_wire_page+0x6b/frame 0x220e0650 i915_gem_object_get_pages_gtt(8af4700,2189a000,102,22569800,1000,...) at i915_gem_object_get_pages_gtt+0xb0/frame 0x220e0684 i915_gem_object_pin(8af4700,0,0,0,22779000,...) at i915_gem_object_pin+0x3ca/frame 0x220e06c0 i915_gem_execbuffer_reserve_object(5f,4f2a700,8af2b5c,18e59a5c,22779110,...) at i915_gem_execbuffer_reserve_object+0x64/frame 0x220e06e8 i915_gem_execbuffer_reserve(22209e00,22779110,20,24da9600,0,...) at i915_gem_execbuffer_reserve+0x1e8/frame 0x220e0720 i915_gem_do_execbuffer(220e0b70,28f2a000,11,fffffff3,22569800,...) at i915_gem_do_execbuffer+0x845/frame 0x220e09a8 i915_gem_execbuffer2(22569800,220e0b70,22505200,69,21ca3410,...) at i915_gem_execbuffer2+0xf6/frame 0x220e09c8 drm_ioctl(1847fa00,c0406469,220e0b70,7,22209e00) at drm_ioctl+0x31b/frame 0x220e09f4 devfs_ioctl(220e0a60) at devfs_ioctl+0x99/frame 0x220e0a2c VOP_IOCTL_APV(10c0614,220e0a60) at VOP_IOCTL_APV+0x18/frame 0x220e0a40 vn_ioctl(218a3070,c0406469,220e0b70,22291d00,22209e00) at vn_ioctl+0x13a/frame 0x220e0af0 devfs_ioctl_f(218a3070,c0406469,220e0b70,22291d00,22209e00) at devfs_ioctl_f+0x2c/frame 0x220e0b18 kern_ioctl(22209e00,a,c0406469,220e0b70) at kern_ioctl+0x1ea/frame 0x220e0b50 sys_ioctl(22209e00,2220a090,220e0cdc,22209e00,3206,...) at sys_ioctl+0xd4/frame 0x220e0c08 syscall(220e0ce8,3b,3b,3b,ffbfeb90,...) at syscall+0x1fd/frame 0x220e0cdc Xint0x80_syscall() at 0xffc033f9/frame 0x220e0cdc --- syscall (54, FreeBSD ELF32, sys_ioctl), eip = 0xffc05f6c, esp = 0xffc07fe8, ebp = 0xffbfeb54 --- panic: sleeping thread cpuid = 0 time = 1586967582 KDB: stack backtrace: db_trace_self_wrapper(aee2f1,1,21935470,1828d8e4,a0f170,...) at db_trace_self_wrapper+0x2a/frame 0x1828d8b8 kdb_backtrace(2,80,22209e00,8a5fa00,c,...) at kdb_backtrace+0x2e/frame 0x1828d918 vpanic(1002aba,1828d954,1828d954,1828d968,c7a399,...) at vpanic+0x11f/frame 0x1828d934 panic(1002aba,c,8a5fa00,17ffe000,8a5fa00,...) at panic+0x14/frame 0x1828d948 propagate_priority(0,246,0,0,22209e00,...) at propagate_priority+0x239/frame 0x1828d968 turnstile_wait(8a5fa00,22209e00,0) at turnstile_wait+0x285/frame 0x1828d984 __rw_wlock_hard(2239ec3c,22209e00) at __rw_wlock_hard+0x40d/frame 0x1828da00 swp_pager_async_iodone(18ef1000,0,157000,ffffffff,18eec000,...) at swp_pager_async_iodone+0x294/frame 0x1828da24 bufdone(18ef1000) at bufdone+0x60/frame 0x1828da64 swapgeom_done(18eec000) at swapgeom_done+0x44/frame 0x1828da7c g_io_deliver(18eec000,0) at g_io_deliver+0x1e7/frame 0x1828dab8 g_std_done(2eae4b58) at g_std_done+0x78/frame 0x1828dacc g_io_deliver(2eae4b58,0) at g_io_deliver+0x1e7/frame 0x1828db08 g_std_done(246ee108) at g_std_done+0x78/frame 0x1828db1c g_io_deliver(246ee108,0) at g_io_deliver+0x1e7/frame 0x1828db58 g_disk_done(2ce1fd68,28,18f5e000,0,0,...) at g_disk_done+0x10a/frame 0x1828db8c adadone(8bfd880,2cddc800) at adadone+0x86e/frame 0x1828dbcc xpt_done_process(25a51,8ad8e68e,e7c6bed,18058000,0,...) at xpt_done_process+0x3fd/frame 0x1828dbf8 xpt_done_direct(2cddc800) at xpt_done_direct+0x39/frame 0x1828dc1c ahci_ch_intr_direct(18058000) at ahci_ch_intr_direct+0xe6/frame 0x1828dc48 ahci_intr_one(17fab454) at ahci_intr_one+0x23/frame 0x1828dc5c ithread_loop(8e23ea0,1828dce8) at ithread_loop+0x1a0/frame 0x1828dcb8 fork_exit(be4b10,8e23ea0,1828dce8,0,0,...) at fork_exit+0x66/frame 0x1828dcd4 fork_trampoline() at 0xffc0340e/frame 0x1828dcd4 --- kthread start KDB: enter: panic 0x00c1e379 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:393 393 savectx(&dumppcb); (kgdb) #0 0x00c1e379 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:393 #1 0x009c0a89 in db_fncall_generic (addr=<optimized out>, nargs=0, args=<optimized out>, rv=<optimized out>) at /usr/src/sys/ddb/db_command.c:610 #2 db_fncall (dummy1=405329652, dummy2=false, dummy3=145217792, dummy4=0x1828d6f0 "pT\223!\f\327(\030", <incomplete sequence \361\240>) at /usr/src/sys/ddb/db_command.c:658 #3 0x009c05c8 in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x009c032c in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x009c3426 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:253 #6 0x00c64c39 in kdb_trap (type=3, code=0, tf=0x1828d8cc) at /usr/src/sys/kern/subr_kdb.c:699 #7 0x00f9324a in trap (frame=0x1828d8cc) at /usr/src/sys/i386/i386/trap.c:668 #8 0xffc0319f in ?? () #9 0x1828d8cc in ?? () #10 0x00000028 in ?? () #11 0x00000028 in ?? () #12 0x00000100 in ?? () #13 0x0101ae42 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (kgdb) -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CBB8F199-5292-4AC6-90C5-53FADE0F04F7>