On 09/01/09 23:02, Steve Gonczi wrote: > Hello, > > I am debuggin a doors problem. My question is: how should I interpret the > door_pc field in the door_node? > As per the Mauro/McDougall book it contains the address of the function that > services the door. > > It does not look like a fully formed 64 bit address, as I cannot just do a > xxxx:dis on it. > Looks more like some sort of an offset, but an offset from what? > The door_pc points to the address of the user land function (server procedure parameter of door_create(3DOOR) which gets executed when the door_call is made. Doing ::dis on that address does not work when 'mdb' is invoked as 'mdb -k'. You could do the ::dis on door_pc when mdb is inovked on the door server process [mdb -p <pid>] > I am looking at a CIFS problem that surfaced recently. I see many smb > threads stuck > waiting forever on pool->dp_cv having called into door_get_server(). > Obviously there are no threads > available in the thread pool of whatever this particular door is. > > It would be interesting to know which function, and perhaps walk the threads > in the > door's thread pool. Are they blocked? Did they go away but forgot to call > door_release_server()? > > Any elucidation of the door_pc field would be much appreciated. > A hint on walking the thread pool of a given door would also be useful. > You would have to chase the 'dp_threads' member of the door_node and then follow the kthread's t_door which is 'struct door data' and use the d_server member of it.
Pramod > Steve >
