Changes between Version 1 and Version 2 of Ticket #700, comment 2


Ignore:
Timestamp:
2017-11-01T17:35:19Z (7 years ago)
Author:
Jakub Jermář

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #700, comment 2

    v1 v2  
    66  1. `devman` enters loc_register_tree_function() and loc_service_register(); sends LOC_SERVICE_REGISTER(1027) to `locsrv` followed by IPC_M_DATA_WRITE(7)
    77  1. `locsrv` for some reason does not reply to the LOC_SERVICE_REGISTER request; since there is no IPC on which LOC_SERVICE_REGISTER depends directly, this could mean that the request in `locsrv` is blocking on a synchronization primitive
    8   1. `locsrv` itself has 4 (!) active calls (method=1024) to ethip; had it been a single request, I would say this is LOC_EVENT_CAT_CHANGE(1024), but in this case I am not sure.
    9   1. `ethip` is itself not answering any of the four 1024 calls from `locsrv` and sends NIC_SET_STATE(NIC_STATE_ACTIVE) to `e1k`; it blocks in ethip_nic_check_new()->ethip_nic_open()->nic_set_state() and holds ethip_discovery_lock to prevent other invocations of ethip_nic_check_new()
     8  1. `locsrv` itself has 4 (!) active calls (method=1024) to ethip; I think these are LOC_EVENT_CAT_CHANGE(1024) messages sent one after another, probably by drivers that added themselves into a category, but we don't see them now because event change notification happens after enlisting in a category is completed.
     9  1. `ethip` is itself not answering any of the four LOC_EVENT_CAT_CHANGE calls from `locsrv` and sends NIC_SET_STATE(NIC_STATE_ACTIVE) to `e1k`; it blocks in ethip_nic_check_new()->ethip_nic_open()->nic_set_state() and holds ethip_discovery_lock to prevent other invocations of ethip_nic_check_new()
    1010  1. `e1k` sends HW_RES_ENABLE_INTERRUPT for IRQ 11 to `pciintel`
    1111  1. `pciintel` sends IPC_CONNECT_ME_TO(2) to `ns` which in turn forwards it to `devman`
    1212  1. `devman` tries to handle the call in devman_connection_device(), but gets blocked on the device_tree.rwlock which was locked in step 3 by fun_online()
    13 
    14 Some notes about the things I don't know. Speculations follow:
    15 
    16 If in step 6 the four messages sent by `locsrv` to `ethip` are indeed LOC_SERVICE_REGISTER, then they are sent from loc_category_change_event(), which takes the callback_sess_mutex. Currently, there can be IPC_MAX_ASYNC_CALLS=4 active calls per one phone. This means that if there are more than 4 callback sessions in the callback_sess_list all going to a single destination, the whole fibril will be blocked inside the callback_sess_mutex-protected critical section. This would correspond to the blocked `nconfsrv` which is waiting for LOC_CALLBACK_CREATE reply from `locsrv`. This message could not be answered at this point because callback_sess_mutex is held. I don't, however, see how `ethip` could have over 4 callbacks registered at `locsrv`.