driver-discuss-requ...@opensolaris.org wrote:
Send driver-discuss mailing list submissions to
driver-discuss@opensolaris.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
or, via email, send a message with subject or body 'help' to
driver-discuss-requ...@opensolaris.org
You can reach the person managing the list at
driver-discuss-ow...@opensolaris.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of driver-discuss digest..."
Today's Topics:
1. Re: Device Driver Shutdown (Garrett D'Amore)
----------------------------------------------------------------------
Message: 1
Date: Sat, 20 Feb 2010 07:05:57 -0800
From: "Garrett D'Amore" <gdam...@sun.com>
To: driver-discuss@opensolaris.org
Subject: Re: [driver-discuss] Device Driver Shutdown
Message-ID: <4b7ffa55.2020...@sun.com>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
On 02/18/10 03:39 PM, John Martin wrote:
On 02/18/10 05:46 PM, Josh Morris wrote:
Hello list,
I have written a device driver for a NAND flash disk for OpenSolaris.
On a safe system shutdown the driver needs to issue a shutdown
command to the disk. I am having problems finding what mechanisms are
available for accomplishing this in my driver. It doesn't look the
detach() function is called on a system shutdown and I have been
unable to find any other driver entry points that are called on a
shutdown. ....
Is the driver attached the system shutdown happens?
If fast reboot is enabled (default) your driver may only
receive a quiesce(9E) call. Is this a character driver and
if so, what does your dev_ops structure look like?
For a clean shutdown, SMF is preferred.
For a "non-clean" shut-down, or if someone just types "reboot" (quite
common!), you wind up skipping the normal smf process.
There used to be a reset() entry point for this, but its obsolete now,
and I don't think it is called ... but you can check.
There is no reset(9E), and dev_ops(9S) says it is obsolete ... but it is
still used
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/devcfg.c#4143
...it came back into use (as a private interface) after being marked
obsolete
to give drivers a chance to flush write cache on shutdown...
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/dktp/controller/ata/ata_common.c#221
(I had a similar
problem on a platform that needed to reset the PCI bus because a reboot
didn't cycle power -- an older SPARC platform at a 3rd party -- back
then I used reset -- but that was in the S8/S9 era.) quiesce() will be
called unless a prom reboot is issued -- which can happen if the
customer configures it, on certain panic situations, or if some other
device doesn't support quiesce.
You can't count on end-user configuration.
Device manufacturers would be well advised not to depend too heavily on
a clean OS-initiated shut down.
One possible approach is to put the device into a state that the next
driver can detect, and can do the appropriate clean up on reboot. Of
course, that won't help if you lose power.
(On device capacitors can help there...)
- Garrett
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
------------------------------
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
End of driver-discuss Digest, Vol 53, Issue 16
**********************************************
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
