[ofw] RE: Ibbus as a filter driver for mthca.

[Smith, Stan]

Tzachi Dar wrote:
> Having to do a reboot after each driver update will make our lives as
> developers close to impossible.
>
> We need to have this issue solved before we proceed.

I agree, working on it!  :-)

>
> (If we are lucky, than this problem was caused, because opensm was
> running, or WSD was installed).
>
> Thanks
> Tzachi
>
>> -----Original Message-----
>> From: Fab Tillier [mailto:ftillier at windows.microsoft.com]
>> Sent: Tuesday, August 05, 2008 9:23 PM
>> To: Smith, Stan; Reuven Amitai; Leonid Keller; Tzachi Dar;
>> Alex Estrin; James Yang; Ishai Rabinovitz
>> Cc: ofw at lists.openfabrics.org
>> Subject: RE: Ibbus as a filter driver for mthca.
>>
>>>> I have few questions from what I saw:
>>>> 1. Disable/Enable require restart:
>>>>     Trying to disable/enable mthca device require a reboot in order
>>>> to complete the operation.
>>>
>>> Yes - mthca disable invokes a reboot request. Is this 'new' behavior
>>> in that the 'current' mthca driver upon right-click disable does not
>>> require a reboot?
>>
>> Correct, right now disabling mthca does not require a reboot.
>>  Requiring a reboot effectively requires a reboot after any
>> driver update.  Probably a reference counting issue related
>> to the device objects or something similar.
>>
>>> I'm not sure if this can be stopped/corrected?
>>
>> It should be able to be corrected.
>>
>>> Fab, is a reboot required or is it possible to defeat the reboot by
>>> some .inf driver setting?
>>
>> Reboot is not required normally - that's one of the goals of
>> PnP.  So something is 'broken' currently.
>>
>>> IPoIB enable/disable does not require a reboot.
>>>
>>>>     Uninstall the device and re-install it using the .inf require
>>>>     reboot as well. Did you have the same phenomenon ? (It happens
>>>> even     right after clean install)
>>>
>>> I would expect a device uninstall to request a reboot.
>>
>> No, it shouldn't.
>>
>>> In the bigger picture, customers not so often enable/disable an HCA
>>> device. For you and I during development, we do; a minor although
>>> irritating problem.
>>
>> They do whenever they update drivers.
>>
>>>> 2. Attached DevTree images after clean install on a machine with
>>>> one HCA (mt25204) which has one port.
>>>>    From the images it seems that ibbus reports on the same port
>>>>    twice and mthca also report for this port. (When tested on
>>>>    machine with 2 HCA with 2 port each, 8 child objects were
>>>>    reported by ibbus and 4 by mlx4_hca) I think that mthca report
>>>>    is happen since get_relation function is still in
>>>>    p_ci_interface and mthca replies to PnP messages using this
>>>> function (which goes to ibbus get_relation). I don't have a clue
>>>> about ibbus reports.
>>>
>>> Interesting, there does seem to be duplication in reporting
>>> relations. As I remember, mthca uses the
>>> p_ci_interface->get_relations call only when mthca receives a
>>> QUERY_REMOVE_DEVICE; removal relations reporting. Since the bus
>>> driver is correctly reporting bus relations and there exists an
>>> implicit relation between the bus driver and mthca driver (same
>>> device stack, mthca cannot unload until it's instance of ibbus
>>> unloads). Possibly, the mthca driver should not be reporting
>>> relations like it does; one step closer to simple?  Do you know
>>> where in mthca relations are reported?
>>
>> This could be the problem with the reboot.  An easy work
>> around without changing mthca is to have the get_relations
>> function return without updating the child device list
>> (basically turn it into a noop).
>>
>> -Fab