On Tuesday, March 04, 2008 3:56 PM, Andrew Morton wrote: > > From: Krzysztof Oledzki <olel@xxxxxx> > > Don't oops if NumPhys==0, instead return -ENODEV. > This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=9909 > > Signed-off-by: Krzysztof Piotr Oledzki <ole@xxxxxx> > Cc: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> > Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Cc: Eric Moore <Eric.Moore@xxxxxxx> > Cc: Sathya Prakash <sathya.prakash@xxxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > --- > > drivers/message/fusion/mptsas.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff -puN > drivers/message/fusion/mptsas.c~mpt-fusion-dont-oops-if-numphy > s==0 drivers/message/fusion/mptsas.c > --- > a/drivers/message/fusion/mptsas.c~mpt-fusion-dont-oops-if-numphys==0 > +++ a/drivers/message/fusion/mptsas.c > @@ -1701,6 +1701,11 @@ mptsas_sas_expander_pg0(MPT_ADAPTER *ioc > if (error) > goto out_free_consistent; > > + if (!buffer->NumPhys) { > + error = -ENODEV; > + goto out_free_consistent; > + } > + > /* save config data */ > port_info->num_phys = buffer->NumPhys; > port_info->phy_info = kcalloc(port_info->num_phys, > _ > This patch seems fine, and we already have this patch in our internal sources. The reason your getting a zero phy count, that is you've got an expander that is zoned to initator A, and initiator B doesn't not have access to those phys hence why its receiving a zero phy count. Ulitmately I have an solution in my next generation driver, in that is I keep the sas address of the expander at a higher level above the phys struct. For this driver, what I propose is we create a phy[0] which really isn't there, and its merely storing the sas_address, but doing this, the expander can be added to the sas transport layer. The driver already has assumptoins that phy 0 will always be there. With only the patch above, the expander doesn't get added. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html