On Wed, Mar 17, 2010 at 08:30:52AM -0600, Rick McNeal wrote: > > On 16-Mar-2010, at 8:17 PM, Edward Pilatowicz wrote: > > > On Tue, Mar 16, 2010 at 03:36:36PM -0600, Rick McNeal wrote: > >> Hi, > >> > >> I hope you don't mind me sending you email directly. > >> > > > > not really, but if there's no personal or private information in emails > > like this i prefer that the discussion happen on public aliases so that > > it gets archived, is searchable, etc. > > > > I was thinking that once I/we figure out this problem I would post a summary > to driver-discuss to giving the results. I have no issue posting any back and > forth exchange we might have and have Cc'd driver-discuss on this reply. > > >> I looked at xdfs_probe() and found that I could change the code such that > >> ddi_get_soft_state() would be called only if there was a valid instance. > >> Basically I changed the following: > >> > >> if (xdfs_pv_disable || pv_disable) > >> return (xdfs_hvm_probe(dip, path)); > >> > >> to: > >> > >> if (xdfs_pv_disable || pv_disable || (instance == -1)) > >> return (xdfs_hvm_probe(dip, path)); > >> > >> Of course, once that's done the kernel panic in xdfs_hvm_probe because > >> instance is -1. Same problem. > >> > >> Can you tell me why the 'sd' driver in the PV case wouldn't have a valid > >> instance? I would think the system would load the 'sd' driver as part of > >> the normal probe/attach configuration of an HBA. > >> > > > > if a device node hasn't yet been promoted to the DS_INITIALIZED state, > > then the device won't have an instance number assigned to it and hence > > will have an instance valud of -1. normally, a devices probe entry > > point is called after the device is in the DS_INITIALIZED state, and if > > the probe entry point returns success the device is transitioned into > > the DS_PROBED state. (see i_ndi_config_node()). > > > > sd nodes are normally managed by their parent hba driver with the help > > of the scsa framework. so it's surprising to see that we're calling > > probe for a node that has an invalid instance. my first instict would > > be that this seems like a target device configuration in the hba driver > > or the scsa framework. > > I'm still thinking I must be doing something wrong in my hba driver or with > it's configuration, but I don't see how. As you say, the hba driver works > with the SCSA framework and it's that framework which is invoking the probe > function in the 'sd' driver which is panic'ing. >
it's also possible that the scsi hba device enumeration works differently from other device enumeration and instance assignment doesn't happen until sometime after probe. (in which case the hvm sd driver won't work in that environment, but as i mentioned before the hvm sd driver was really only designed to work with ide cdrom devices.) i'm not a scsi device enumeration expert. looking at the native sd driver, i see that it doesn't actually use instance numbers in it's probe routine, so it's unlikely that you'll see the same panic with the native driver. ed _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
