| 6 | | 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) |
| 7 | | 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; 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() |
| | 6 | 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); the connection to `locsrv` is "serialized" and so it uses only a single phone |
| | 7 | 1. `locsrv` does not reply to the LOC_SERVICE_REGISTER request because the fibril which is handling connections from `devman` is itself blocked |
| | 8 | 1. `locsrv` itself has 4 active LOC_EVENT_CAT_CHANGE(1024) calls to `ethip`; these had all been sent one after another by drivers that already added themselves into a category, but we don't see them now because event change notifications happen after enlisting in a category is completed (ie. after the request is answered). |
| | 9 | 1. `ethip` is itself not answering any of the four LOC_EVENT_CAT_CHANGE calls from `locsrv` and blocks on NIC_SET_STATE(NIC_STATE_ACTIVE) to `e1k` |
