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

[Tzachi Dar]

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.

(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
>