|Posted: Wed Aug 10, 2005 8:51 pm Post subject:|
Thank you for the information.
The IBVolume plugin supports multiple sessions (clustering).
Ever more, the old RamDisk plugin supports clustering too in the version. :)
|Posted: Wed Aug 10, 2005 11:20 pm Post subject:|
|Unfortunately this build isn't going well for me.|
The problems so far:
On the Target machine:
1) 0x00000050: PAGE_FAULT_IN_NONPAGED_AREA in videport.sys when the initiator connects to an SPTI device.
2) Hard lock-ups, no mouse or KB, system dead after adding SPTI device.
I removed Via IDE Accelerator 1.20b so the default Microsoft IDE drivers are now used. This seems to have fixed 1) and 2).
On the initiator machine:
3) 0x000000D1: DRIVER_IRQL_NOT_LESS_OR_EQUAL in starport.sys when connecting to this build of Starwind.
(Address EF914544 base at EF90F000, datestamp 42308185)
4) Hard lock for about 30 seconds then start to work again for about 10 seconds, then hard lock for 30 seconds and so on until I remove the device from starport.
|Posted: Thu Aug 11, 2005 6:46 am Post subject:|
1) and 2) - seem to be a bug/issues of the Via drivers.
StarWind is purely a usermode application, it has no kernel drivers in the installation.
3-4) Have you tried the MS initiator on the client machine? Does it work?
|Posted: Thu Aug 11, 2005 10:04 am Post subject:|
I only mentioned this because the previous RC build did not give such errors (2.6.3 date 20050730).
Yep works fine! I have connected and used a shared SPTI device without any problems.
|Posted: Thu Aug 11, 2005 11:52 am Post subject:|
The SPTI module sends IOCTL_SCSI_* to devices. A storage port driver is required not to crash whatever a user app sends to it. So this is a question to the VIA developers, why their driver behaves so bad...
I guess nothing changed in the SPTI module since build 2005-07-30, so it's strange thing...
What is your initiator system? Are there any third-party drivers (storage or filters)?
|Posted: Thu Aug 11, 2005 2:02 pm Post subject:|
Hmmm, can't seem to reproduce the problem.
I suspect it's because the target problems left a strange entry in the StarPort Remote iSCSI devices list.
It had TID 1, blank Vendor ID, Product ID and Revision, Type Disk.
I cleared this out and it appears to be working OK now.
I'll keep testing!
|Posted: Thu Aug 11, 2005 2:16 pm Post subject:|
Good news! :)
There is may be be some hidden bug in StarPort driver that leads to crashes on failed reconnection to a target...
Please let us know if you have any news about the case.
Thank you in advance.
|Posted: Thu Aug 11, 2005 2:32 pm Post subject:|
I just want to clarify what went on.
When the StarWind target machine was going BSOD or just dying the StarPort client would, after a short delay, seem to complete and add the odd entry described above.
I now believe that the 10 second auto refresh was causing the apparent locked/not-locked cycle that I saw.
This duff enrtry must have given StarPort some problems thus giving the lock-ups and eventually the BSOD.
So the question has to asked :
Why did this duff entry appear when the target had died?
Why was it so bad for StartPort to have this duff entry?
|Posted: Thu Aug 11, 2005 2:57 pm Post subject:|
We'll try to pin out the issue and fix it...
Thank you for the feedback again.
|Posted: Sat Aug 13, 2005 8:52 pm Post subject:|
|A minor thing I just found.|
The 'Choose name of target' panel does not remember previously typed names.
Errm, that's it for now
|Posted: Sat Aug 13, 2005 9:52 pm Post subject:|
Ok, we'll try to fix the issue in the next build. :)