My understanding is the network stack is not functional at the time a
storage stack needs to mount the system disk. It sounds like you maybe
mucked with the normal driver start order?
yes, you are right.
A storage stack will get a shutdown notification, AFTER almost everything
else, as it needs to keep functioning while the file system drivers flush
buffers,and mark the volume as clean. A serious problem is EVERYTHING that
might be touched for doing paging I/O must be page locked. You basically
can’t be touching paged code or data, that might be paged out on the volume
that is being unmounted (i.e. the system disk).
according to your comment, my SCSI miniport driver is certainly involved in the path of paging I/O, and although i can ensure that all code and data the SCSI miniport driver is accessing are in non-paged memory, the MS tcpip.sys or NIC driver are not designed for diskless enviroment, so they may be touching paged code or data, or the worst case, may already be unloaded, when shutdown, and that’s why the system hang up.
BTW: since i can alter the driver load order, is there any way to determine the order of driver unload?
This doesn’t help the above issue. My understanding is the only viable
strategy for a diskless system would be write a SCSI miniport that had its
own internal protocol stack (i.e. TCP/IP) and knew how to directly control a
network card.
I’ll study your suggestion, thanks.
Weiyu, Dong
ÑÅ»¢Ãâ·ÑGÓÊÏä£ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä
ÑÅ»¢ÖúÊÖ¡§DËÑË÷¡¢É±¶¾¡¢·ÀɧÈÅ