On Wed, Mar 17, 2010 at 03:46:04PM -0600, Rick McNeal wrote: > > On 17-Mar-2010, at 3:20 PM, Edward Pilatowicz wrote: > > <sniped> > >> > >> 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. > > > > Unless I'm looking at something different the native 'sd' driver DOES use > instance numbers in it's probe routine. That code is commented out if > XPV_HVM_DRIVER is defined. This is also consistent with the panic I get when > I removed the i86hvm/kernel/drv/sd driver. > > The kernel now panic's with sd:sd_probe() on the stack. The assert is still > in ddi_get_soft_state(). >
oops. your right. i was reading that ifndef backwards. (i was thinking we only accessed the instance number if XPV_HVM_DRIVER was defined.) ed _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
