Fwd: KASSERT in vm_map.c

[Hans Petter Selasky]

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 at bitfrost.no>
>> To: Konstantin Belousov <kib at 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