Date: Mon, 10 Mar 2014 09:23:41 +0100 From: Hans Petter Selasky <hps@bitfrost.no> To: John Baldwin <jhb@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: Fwd: KASSERT in vm_map.c Message-ID: <531D768D.2040904@bitfrost.no> In-Reply-To: <201403061624.52580.jhb@freebsd.org> References: <530EFC76.9010302@bitfrost.no> <53181EC1.90103@bitfrost.no> <201403061624.52580.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <hps@bitfrost.no>
>> To: Konstantin Belousov <kib@FreeBSD.org>
>>
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?531D768D.2040904>