From owner-freebsd-stable@FreeBSD.ORG Mon Mar 10 08:23:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9FA6FB5; Mon, 10 Mar 2014 08:23:25 +0000 (UTC) Received: from mta04.bitpro.no (mta04.bitpro.no [92.42.64.203]) by mx1.freebsd.org (Postfix) with ESMTP id 613BE6C0; Mon, 10 Mar 2014 08:23:25 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta04.bitpro.no (Postfix) with ESMTPS id 579181001FA; Mon, 10 Mar 2014 09:23:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 767901822C9; Mon, 10 Mar 2014 09:24:17 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG-VS1CuF5BM; Mon, 10 Mar 2014 09:24:10 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id BBEC9182293; Mon, 10 Mar 2014 09:23:58 +0100 (CET) Message-ID: <531D768D.2040904@bitfrost.no> Date: Mon, 10 Mar 2014 09:23:41 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Baldwin , freebsd-stable@freebsd.org Subject: Re: Fwd: KASSERT in vm_map.c References: <530EFC76.9010302@bitfrost.no> <53181EC1.90103@bitfrost.no> <201403061624.52580.jhb@freebsd.org> In-Reply-To: <201403061624.52580.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 08:23:26 -0000 On 03/06/14 22:24, John Baldwin wrote: > On Thursday, March 06, 2014 2:07:45 am Hans Petter Selasky wrote: >> FYI >> >> -------- Original Message -------- >> Subject: KASSERT in vm_map.c >> Date: Thu, 27 Feb 2014 09:51:02 +0100 >> From: Hans Petter Selasky >> To: Konstantin Belousov >> >> Hi, >> >> Using 9-stable I hit a KASSERT when EHCI is loading: >> >> --- a/sys/vm/vm_map.c >> +++ b/sys/vm/vm_map.c >> @@ -2301,9 +2301,11 @@ vm_map_unwire(vm_map_t map, vm_offset_t start, >> vm_offset_t end, >> * Mark the entry in case the map lock is released. (See >> * above.) >> */ >> +#if 0 >> KASSERT((entry->eflags & MAP_ENTRY_IN_TRANSITION) == 0 && >> entry->wiring_thread == NULL, >> ("owned map entry %p", entry)); >> +#endif >> entry->eflags |= MAP_ENTRY_IN_TRANSITION; >> entry->wiring_thread = curthread; >> /* >> >> >> Is the KASSERT() wrong or is my USB code wrong. > > The KASSERT is correct. Can you provide more details from your panic? (Do you have > a crash dump?) It sounds like two threads are mucking with the same vm_map_entry at > the same time. > Hi John, Changed assert a bit: KASSERT((entry->eflags & MAP_ENTRY_IN_TRANSITION) == 0 && entry->wiring_thread == NULL, ("owned map entry %p 0x%x 0x%x %p %p", entry, entry->eflags, MAP_ENTRY_IN_TRANSITION, entry->wiring_thread, curthread)); Got this: KASSERT: 0x00000000 0x00000100 0xffffffffffffffff 0xfffffe0004205490 KDB: stack backtrace: #0 0xffffffff808e9e46 at kdb_backtrace+0x66 #1 0xffffffff80b19b0b at vm_map_wire+0x11b #2 0xffffffff80b12177 at kmem_alloc_contig+0x247 #3 0xffffffff80b121c9 at contigmalloc+0x39 #4 0xffffffff80d7c361 at alloc_bounce_pages+0x51 #5 0xffffffff80d7c53f at bus_dmamap_create+0xff #6 0xffffffff807179ce at usb_pc_dmamap_create+0x3e #7 0xffffffff80732e59 at usbd_transfer_setup_sub+0x559 #8 0xffffffff806fc379 at ehci_xfer_setup+0x469 #9 0xffffffff8073216f at usbd_transfer_setup+0x2ff #10 0xffffffff807327fc at usbd_ctrl_transfer_setup+0xbc #11 0xffffffff8072cdd4 at usbd_do_request_flags+0x394 #12 0xffffffff8072df81 at usbd_req_set_address+0xc1 #13 0xffffffff80720c91 at usb_alloc_device+0x461 #14 0xffffffff80728c38 at uhub_explore+0x5b8 #15 0xffffffff807133ea at usb_bus_explore+0xaa #16 0xffffffff8072c7d3 at usb_process+0xc3 #17 0xffffffff80881d45 at fork_exit+0x135 Looks like the wiring_thread variable is dirty. Sometimes it is 0xffffffffffffffff other times other values. --HPS