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.

> 
>> Is it possible to remove this PV version of 'sd' and enable the HVM version 
>> of 'sd'?
>> 
> 
> sure.  all the PV drivers live in:
>       /platform/i86hvm
> 
> if you move aside that directory you'll have no PV drivers on the system
> (remember to rebuild the boot archive via bootadm update-archive after
> you do this.)
> 

I don't want to remove all of the drivers.

> you could also just disable the pv sd driver by moving aside:
>       /platform/i86hvm/kernel/drv/sd
>       /platform/i86hvm/kernel/drv/amd64/sd
> 
> let me know if any of this helps.
> 

I'll give this a shot.

> ed
> 
> 
>> On 15-Mar-2010, at 11:13 AM, Edward Pilatowicz wrote:
>> 
>>> interesting.  so i'm guessing that you're running in an HVM domU.  if
>>> that's correct, the sd "driver" is actually a thin wrapper that
>>> redirects all accesses to the xdfs driver (the true PV disk driver).  i
>>> wrote that wrapper and it's only been written to support sd cdrom
>>> devices, it doesn't actually support sd disk devices.  (since by default
>>> HVM domUs only have ide disk devices, which use cmdk, which is also a
>>> shell wrapper driver in HVM environments.)  that said, i wrote the sd
>>> wrapper so that if it detects a disk it should fall back to using the
>>> emulated HVM access.  that auto-detection would happen in xdfs_probe().
>>> apparently that logic doesn't quite work...
>>> 
>>> ed
>>> 
>>> 
>>> 
>>> On Sat, Mar 13, 2010 at 03:34:18PM -0700, Rick McNeal wrote:
>>>> I've got a driver which runs on a domU that communicates with another OS 
>>>> on a different domU. Right now I can get the driver attached and see 30+ 
>>>> SCSI INQUIRY commands sent to the driver and receive responses. 
>>>> Unfortunately the kernel then panic's in ddi_get_soft_state() which is 
>>>> called by sd:xdfs_probe(). ddi_get_soft_state() will panic if either the 
>>>> state pointer is NULL or the instance number is less than 0. From the 
>>>> stack information the instance number is -1. xdfs_probe() calls 
>>>> ddi_get_instance() which is returning the -1, so I looked at the dip value.
>>>> 
>>>>> ffffff00ee825540::devinfo
>>>> ffffff00ee825540 sd (driver not attached)
>>>>       System properties at ffffff00ee826c80:
>>>>           name='lun' type=int items=1
>>>>               value=00000000
>>>>           name='target' type=int items=1
>>>>               value=00000000
>>>>           name='class' type=string items=1
>>>>               value='scsi'
>>>>> 
>>>> 
>>>> The sd driver isn't attached which seems to be a big problem.
>>>> 
>>>> So, I figure that the problem is related to something that I'm doing or 
>>>> not doing. Does anyone have a guess?
>>>> 
>>>> In case someone is curious here's the stack trace at the time of the panic.
>>>> 
>>>> assertion failed: (ss != NULL) && (item >= 0), file: 
>>>> ../../common/os/sunddi.c, line: 6445
>>>> 
>>>> 
>>>> ffffff00028d07f0 genunix:assfail+7e ()
>>>> ffffff00028d0820 genunix:ddi_get_soft_state+5d ()
>>>> ffffff00028d0870 sd:xdfs_probe+31 ()
>>>> ffffff00028d08c0 genunix:devi_probe+42 ()
>>>> ffffff00028d0900 genunix:probe_node+66 ()
>>>> ffffff00028d0950 genunix:i_ndi_config_node+118 ()
>>>> ffffff00028d0980 genunix:i_ddi_attachchild+6e ()
>>>> ffffff00028d09c0 genunix:devi_attach_node+fe ()
>>>> ffffff00028d0a20 genunix:config_immediate_children+f5 ()
>>>> ffffff00028d0aa0 genunix:ndi_busop_bus_config+c7 ()
>>>> ffffff00028d0b10 scsi:scsi_hba_bus_config_spi+142 ()
>>>> ffffff00028d0b70 scsi:scsi_hba_bus_config+d5 ()
>>>> ffffff00028d0bc0 genunix:devi_config_common+94 ()
>>>> ffffff00028d0c40 genunix:mt_config_thread+5d ()
>>>> ffffff00028d0c50 unix:thread_start+8 ()
>>>> 
>>>> 
>>>> ----
>>>> Rick McNeal
>>>> [email protected]
>>>> 
>>>> "It is not the critic who counts, not the man who points out how the 
>>>> strong man stumbled, or where the doer of deeds could have done them 
>>>> better. The credit belongs to the man who is actually in the arena; whose 
>>>> face is marred by dust and seat and blood; who strives valiantly, who errs 
>>>> and comes short again and again; who knows the great enthusiasms, the 
>>>> great devotions, and spends himself in a worthy cause; who, at the best, 
>>>> knows in the end the triumph of high achievement; and who, at the worst, 
>>>> if he fails, at least fails while daring greatly, so that his place shall 
>>>> never be with those cold and timid souls who know neither victory nor 
>>>> defeat." -- Theodore Roosevelt
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> driver-discuss mailing list
>>>> [email protected]
>>>> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>> 
>> ----
>> Rick McNeal
>> [email protected]
>> 
>> "A lie can get halfway around the world before the truth can get its boots 
>> on." - Mark Twain

----
Rick McNeal
[email protected]

“If you see a man approaching you with the obvious intent of doing you good, 
you should run for your life.” —Henry David Thoreau 

_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss

Reply via email to