Re: EVENTHANDLER_DECLARE

2000-05-10 Thread Simon Shapiro


On 10-May-00 Mike Smith wrote:

...

 This is dangerous for the OSM.  When the i2o OSM shuts an IOP
 down, it is history.  It will stop doing any work at all; network,
 disk, console, mouse, whatever.  I reserve that for really, really
 shutdown/reset.
 
 I'm not sure I understand what you mean by "dangerous".  When your 
 shutdown method is called, you're being told that you're about to stop 
 being able to control your hardware, either because your code is about to 
 be removed from the kernel (module unload) or because the system is being 
 shut down.

(perhaps) Dangerous in the sense that the i2o OSM handles multiple
diciplines.  It is not a disk-only driver.  It has a disk component
but if I shut down the IOPs more than just disks stop.
Thus I need to be sure the OSM is the very last to be called.

 Before you return success from your shutdown method, you must have 
 brought your hardware to a quiescent state, ready for immediate loss of 
 power.  It must not generate any more interrupts or access any more data 
 once you have returned.

That is already being done.  Thanx.

 You can veto your shutdown (by returning nonzero), which will fail a 
 module unload, but _will_not_ fail a kernel shutdown.

That is fine.

 This needs to happen after all other shutdown work was done,
 but before a physical reset is sent to the hardware.
 
 There is no telling how long the IOP will take to return
 from flush request.
 
 That's fine.  Again, the Mylex driver is doing exactly what you're 
 talking about; I've been down this path just a few times now. 8)
 
  (Note that the Mylex stuff doesn't correctly handle suspend/resume since 
   we don't have a decent ACPI implementation yet)
 
 I can emulate suspend/resume in the OSM easily.
 Actually, it does that just before shutting down.
 A single line of code.
 
 I'm assuming that you depend on the platform firmware to bring it out of 
 any of the deep sleep modes, re-enumerate the PCI bus and restore all of 
 its volatile state?

Nope.  I maintain a state machine in the OSM that makes sure
there is nothing pending on the IOP.  Shutting down the IOP
is a mess.  Bringing it back up is even bigger mess.  It is
simpler the way I do it.  Besides, different vendors implement
i2o in different ways.  Some do not even have a facility for
sane shutdown.

 -- 
 \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
 \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
 \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

Sincerely Yours
 404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: EVENTHANDLER_DECLARE

2000-05-10 Thread Doug Rabson

On Tue, 9 May 2000, Mike Smith wrote:

  
  On 10-May-00 Mike Smith wrote:
   Sorry to bother y'll, but;
   
   Has anyone ever used that?  I see no trace of any kernel
   code calling it, and the at_shutdown code appears to be
   gone.
   
   It's still used in the shutdown code; it was meant to be available for 
   general use elsewhere, but I haven't seen anyone playing with it, so 
   maybe the design tradeoffs were bad choices.
  
  I dunno.  It seems to do anything I need;  Call me with an argument.
  I do not even need the priority.
 
 It won't notify you that your code is about to be removed from the kernel.
 
   BTW, for all it is worth, any caching controller not using
   this is guaranteed to lose data.
   
   Wrong layer.  You should be using the bus shutdown method; look at eg. 
   the Mylex driver to see how this is done.  You should probably call your 
   flush routine from the suspend method as well.
  
  This is dangerous for the OSM.  When the i2o OSM shuts an IOP
  down, it is history.  It will stop doing any work at all; network,
  disk, console, mouse, whatever.  I reserve that for really, really
  shutdown/reset.
 
 I'm not sure I understand what you mean by "dangerous".  When your 
 shutdown method is called, you're being told that you're about to stop 
 being able to control your hardware, either because your code is about to 
 be removed from the kernel (module unload) or because the system is being 
 shut down.

Actually, DEVICE_DETACH is called when the driver is unloaded and it can
return an error which should abort the unload. If DEVICE_SHUTDOWN is
called, then you have no choice - the kernel is stopping soon and this is
your last change to tidy up.

 
 Before you return success from your shutdown method, you must have 
 brought your hardware to a quiescent state, ready for immediate loss of 
 power.  It must not generate any more interrupts or access any more data 
 once you have returned.
 
 You can veto your shutdown (by returning nonzero), which will fail a 
 module unload, but _will_not_ fail a kernel shutdown.

See above - you can veto detach but not shutdown.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 20 8442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: EVENTHANDLER_DECLARE

2000-05-10 Thread Mike Smith

  This is dangerous for the OSM.  When the i2o OSM shuts an IOP
  down, it is history.  It will stop doing any work at all; network,
  disk, console, mouse, whatever.  I reserve that for really, really
  shutdown/reset.
  
  I'm not sure I understand what you mean by "dangerous".  When your 
  shutdown method is called, you're being told that you're about to stop 
  being able to control your hardware, either because your code is about to 
  be removed from the kernel (module unload) or because the system is being 
  shut down.
 
 (perhaps) Dangerous in the sense that the i2o OSM handles multiple
 diciplines.  It is not a disk-only driver.  It has a disk component
 but if I shut down the IOPs more than just disks stop.
 Thus I need to be sure the OSM is the very last to be called.

If you've constructed your bus architecture correctly (ie. the OSM is the 
parent of all the discipline drivers) then the bus subsystem will take 
care of all of this for you. 

(It would be silly to do it any other way.)

  I'm assuming that you depend on the platform firmware to bring it out of 
  any of the deep sleep modes, re-enumerate the PCI bus and restore all of 
  its volatile state?
 
 Nope.  I maintain a state machine in the OSM that makes sure
 there is nothing pending on the IOP.  Shutting down the IOP
 is a mess.  Bringing it back up is even bigger mess.  It is
 simpler the way I do it.  Besides, different vendors implement
 i2o in different ways.  Some do not even have a facility for
 sane shutdown.

Ugh.  In other words, you don't support suspend/resume. 8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: EVENTHANDLER_DECLARE

2000-05-09 Thread Mike Smith

 Sorry to bother y'll, but;
 
 Has anyone ever used that?  I see no trace of any kernel
 code calling it, and the at_shutdown code appears to be
 gone.

It's still used in the shutdown code; it was meant to be available for 
general use elsewhere, but I haven't seen anyone playing with it, so 
maybe the design tradeoffs were bad choices.

 BTW, for all it is worth, any caching controller not using
 this is guaranteed to lose data.

Wrong layer.  You should be using the bus shutdown method; look at eg. 
the Mylex driver to see how this is done.  You should probably call your 
flush routine from the suspend method as well. 

(Note that the Mylex stuff doesn't correctly handle suspend/resume since 
 we don't have a decent ACPI implementation yet)


-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: EVENTHANDLER_DECLARE - solved

2000-05-09 Thread Simon Shapiro

Correction to the below message;

Figured it out all by myself :-)

Thanx!

On 10-May-00 Simon Shapiro wrote:
 Sorry to bother y'll, but;
 
 Has anyone ever used that?  I see no trace of any kernel
 code calling it, and the at_shutdown code appears to be
 gone.
 
 BTW, for all it is worth, any caching controller not using
 this is guaranteed to lose data.
 
 that can range from 4MB to 256MB, all of which the kernel
 is convinced was written to disk.  IOW, disaster.
 
 
 Sincerely Yours
  404.664.6401
 Simon Shapiro Research Fellow, Earthlink Inc.

Sincerely Yours
 404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: EVENTHANDLER_DECLARE

2000-05-09 Thread Simon Shapiro


On 10-May-00 Mike Smith wrote:
 Sorry to bother y'll, but;
 
 Has anyone ever used that?  I see no trace of any kernel
 code calling it, and the at_shutdown code appears to be
 gone.
 
 It's still used in the shutdown code; it was meant to be available for 
 general use elsewhere, but I haven't seen anyone playing with it, so 
 maybe the design tradeoffs were bad choices.

I dunno.  It seems to do anything I need;  Call me with an argument.
I do not even need the priority.

 BTW, for all it is worth, any caching controller not using
 this is guaranteed to lose data.
 
 Wrong layer.  You should be using the bus shutdown method; look at eg. 
 the Mylex driver to see how this is done.  You should probably call your 
 flush routine from the suspend method as well.

This is dangerous for the OSM.  When the i2o OSM shuts an IOP
down, it is history.  It will stop doing any work at all; network,
disk, console, mouse, whatever.  I reserve that for really, really
shutdown/reset.

This needs to happen after all other shutdown work was done,
but before a physical reset is sent to the hardware.

There is no telling how long the IOP will take to return
from flush request.

 (Note that the Mylex stuff doesn't correctly handle suspend/resume since 
  we don't have a decent ACPI implementation yet)

I can emulate suspend/resume in the OSM easily.
Actually, it does that just before shutting down.
A single line of code.

 -- 
 \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
 \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
 \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

Sincerely Yours
 404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: EVENTHANDLER_DECLARE

2000-05-09 Thread Mike Smith

 
 On 10-May-00 Mike Smith wrote:
  Sorry to bother y'll, but;
  
  Has anyone ever used that?  I see no trace of any kernel
  code calling it, and the at_shutdown code appears to be
  gone.
  
  It's still used in the shutdown code; it was meant to be available for 
  general use elsewhere, but I haven't seen anyone playing with it, so 
  maybe the design tradeoffs were bad choices.
 
 I dunno.  It seems to do anything I need;  Call me with an argument.
 I do not even need the priority.

It won't notify you that your code is about to be removed from the kernel.

  BTW, for all it is worth, any caching controller not using
  this is guaranteed to lose data.
  
  Wrong layer.  You should be using the bus shutdown method; look at eg. 
  the Mylex driver to see how this is done.  You should probably call your 
  flush routine from the suspend method as well.
 
 This is dangerous for the OSM.  When the i2o OSM shuts an IOP
 down, it is history.  It will stop doing any work at all; network,
 disk, console, mouse, whatever.  I reserve that for really, really
 shutdown/reset.

I'm not sure I understand what you mean by "dangerous".  When your 
shutdown method is called, you're being told that you're about to stop 
being able to control your hardware, either because your code is about to 
be removed from the kernel (module unload) or because the system is being 
shut down.

Before you return success from your shutdown method, you must have 
brought your hardware to a quiescent state, ready for immediate loss of 
power.  It must not generate any more interrupts or access any more data 
once you have returned.

You can veto your shutdown (by returning nonzero), which will fail a 
module unload, but _will_not_ fail a kernel shutdown.

 This needs to happen after all other shutdown work was done,
 but before a physical reset is sent to the hardware.
 
 There is no telling how long the IOP will take to return
 from flush request.

That's fine.  Again, the Mylex driver is doing exactly what you're 
talking about; I've been down this path just a few times now. 8)

  (Note that the Mylex stuff doesn't correctly handle suspend/resume since 
   we don't have a decent ACPI implementation yet)
 
 I can emulate suspend/resume in the OSM easily.
 Actually, it does that just before shutting down.
 A single line of code.

I'm assuming that you depend on the platform firmware to bring it out of 
any of the deep sleep modes, re-enumerate the PCI bus and restore all of 
its volatile state?

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: EVENTHANDLER_DECLARE

2000-05-09 Thread Peter Wemm

Simon Shapiro wrote:
 
 On 10-May-00 Mike Smith wrote:
  Sorry to bother y'll, but;
  
  Has anyone ever used that?  I see no trace of any kernel
  code calling it, and the at_shutdown code appears to be
  gone.
  
  It's still used in the shutdown code; it was meant to be available for 
  general use elsewhere, but I haven't seen anyone playing with it, so 
  maybe the design tradeoffs were bad choices.
 
 I dunno.  It seems to do anything I need;  Call me with an argument.
 I do not even need the priority.

Well, you need to be called at "shutdown_post_sync" - anything before
that is too soon as the kernel is still potentially pushing data out to
the controller.  This also happens to be where the module and bus shutdown
events are called too.

  BTW, for all it is worth, any caching controller not using
  this is guaranteed to lose data.
  
  Wrong layer.  You should be using the bus shutdown method; look at eg. 
  the Mylex driver to see how this is done.  You should probably call your 
  flush routine from the suspend method as well.
 
 This is dangerous for the OSM.  When the i2o OSM shuts an IOP
 down, it is history.  It will stop doing any work at all; network,
 disk, console, mouse, whatever.  I reserve that for really, really
 shutdown/reset.
 
 This needs to happen after all other shutdown work was done,
 but before a physical reset is sent to the hardware.
 
 There is no telling how long the IOP will take to return
 from flush request.

That is no problem.. you can take as long as you need.  The filesystems
are unmounted, all the system daemons have been shut down, all dirty
data has been pushed to the controller, sync(2) has happened.  The system
will do nothing else until your controller's shutdown method has returned.

If you want to reset it after doing the flush, there is nothing stopping
you - you can do it however you need to.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message