[OFW][patch] partition tool latest OFED

Mon May 12 07:07:22 PDT 2008

Hi Slava,

In the last couple of days I have checked your patch to add partitioning
support to WinIB.

As for the bad side, I have found the following problems:
1) It is only possibale to add a partition to the first port. What
happens if one wants to add partitions to the second port? what happens
if there are more than one card?
2) After partitions are added, it is very hard to tell which interface
is mapped to which pkey. This makes configuration very hard.
3) The number of times that one is asked to do a reboot of the system in
order for his changes to take affect is very big.
4) There was a memory leak in the function __ib_mgr_init (in the case of
error) (already fixed).
5) In the case of remove there is no ioctl, to the bus to do a re-scan.
Is this be design? What will happen in the case of add (1) ,than remove
(1) and later add (2) ?
6) When removing pkeys I have received the following assert:
fffff800`0111c692 : fffff800`0111c770 fffffadf`29c6a070
fffffadf`29c6a040 00000000`00000002 : nt!DbgBreakPoint
fffffadf`27fd6366 : fffffadf`37d97930 fffffadf`29c6aa70
fffffadf`379fb060 00000000`00000000 : nt!RtlAssert+0xf3
fffffadf`27f47095 : fffffadf`37da5010 fffffadf`29c6aa70
fffffadf`379fb060 00000000`00000000 : ibbus!deref_al_obj+0x116
[q:\projinf3\trunk\core\al\al_common.c @ 399]
fffffadf`27f4df82 : fffffadf`37f56760 fffffadf`27f4d700
fffffadf`29c6a640 fffffadf`27f4d6c0 : ibbus!free_port_mgr+0x3f5
[q:\projinf3\trunk\core\bus\kernel\bus_port_mgr.c @ 404]
fffffadf`27f4dd16 : fffffadf`37f56798 fffffadf`00989680
fffffadf`00000000 fffffadf`2d424bb0 : ibbus!__destroy_cb+0x142
[q:\projinf3\trunk\core\complib\cl_obj.c @ 779]
fffffadf`27f4d596 : fffffadf`37f56760 fffff800`00000003
fffffadf`379fb338 fffffadf`29c6aa70 : ibbus!__destroy_obj+0x146
[q:\projinf3\trunk\core\complib\cl_obj.c @ 709]
fffffadf`28044770 : fffffadf`37f56760 fffff800`0131f84a
fffffadf`37d97930 00000000`00000000 : ibbus!cl_obj_destroy+0x66
[q:\projinf3\trunk\core\complib\cl_obj.c @ 313]
fffffadf`27f4e0c9 : fffffadf`379fb060 00000000`00000000
00000000`000000d3 fffffadf`37d97930 : ibbus!fdo_release_resources+0x180
[q:\projinf3\trunk\core\bus\kernel\bus_pnp.c @ 384]
fffffadf`28058113 : fffffadf`379fb060 fffffadf`37d97930
fffffadf`29c6a818 00000000`ffffffff : ibbus!cl_do_remove+0x129
[q:\projinf3\trunk\core\complib\kernel\cl_pnp_po.c @ 693]
fffffadf`280543cf : fffffadf`379fb060 fffffadf`37d97930
fffffadf`29c6a818 00000000`00000000 : ibbus!__remove+0x153
[q:\projinf3\trunk\core\complib\kernel\cl_pnp_po.c @ 661]
fffff800`0133ed04 : fffffadf`379fb060 fffffadf`37d97930
fffffadf`379fb060 00000000`00000000 : ibbus!cl_pnp+0x121f
[q:\projinf3\trunk\core\complib\kernel\cl_pnp_po.c @ 260]
fffff800`010d1cae : fffffadf`379fb000 fffffa80`00b316b0
fffffadf`382dde40 fffffadf`382dde40 : nt!IopSynchronousCall+0x144
fffff800`01340f05 : 00000e48`5532134d 00000000`00000000
fffffa80`01f41320 00000000`80000000 : nt!IopRemoveLockedDeviceNode+0xafd
fffff800`0134666b : fffffadf`28ad0ae8 00000000`00000000
fffffa80`021e59c0 fffffa80`002f0844 :
nt!IopDeleteLockedDeviceNodes+0x135
fffff800`01344755 : 00000000`00000000 fffffadf`388303a0
00000000`00000001 fffffa80`01b495e0 :
nt!PiProcessQueryRemoveAndEject+0x1471
fffff800`0103768a : fffffadf`38003ed0 fffff800`01344500
fffffadf`38807bf0 fffff800`011ce9d8 : nt!PiWalkDeviceList+0x255
fffff800`0124b972 : fffffadf`38807bf0 00000000`00000080
fffffadf`38807bf0 fffffadf`29873680 : nt!ExpWorkerThread+0x13b
fffff800`010202d6 : fffffadf`2986b180 fffffadf`38807bf0
fffffadf`29873680 fffff800`011b5dc0 : nt!PspSystemThreadStartup+0x3e
00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16

As for the good side: 

1) This patch doesn't introduce new problems if partitioning is not
used.

2) If one knows what he is doing, he can add partitioning support.

Possibale solutions that I see to these problems are:

1) Adding partitions on other ports: Solution is relatively simple but
requires some work. There is probably a need to change the registry
interface, the user mode program and the bus driver code.

2) This one seems harder, and I don't have a complete solution. As part
of the solution, the new interfaces that are created by the bus driver
should probably have other names than the normal ones. They can still
use the same INF, but with a different title. It seems that we will
still have to find a way of how to tell the user which pkey is used for
which device.

3) We need to understand what the main reason is for this boots and how
to avoid them.

5) The assert has to be fixed.

After all, in order to allow people to send relatively small patches, I
have decided to apply this patch (with very minor changes) in revision
1160.

I hope to see more work on fixing the issues I have raised in the coming
future.

Thanks

Tzachi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20080512/bb72587a/attachment.html>