S3 Resume working, but IDE disk hung

S3 Resume working, but IDE disk hung

[Faraoni, Michael]

Hi,

 I have been able to get S3 mode to come back to prompt, but the IDE disk is
hung (drive light constantly on).  Running an app that isn't in disk cache
or that accesses the disk causes the app to hang, presumably blocked on I/O.
This indicates that the IDE drivers are not yet S3 suspend/resume capable
(the IDE controller/devices are not being restored properly), which I
expected at this stage.

 I am using an Intel Motherboard with an i810 chipset (using piix IDE PCI
driver), and 2.5.40 kernel with ACPI 20021002 diff applied.

 The IDE drivers seem to have some suspend/resume infrastructure. Does any
one know the direction that is being taken?  I am willing to help
implement/test, but want to know bigger picture/plan before starting (if
known?).

 I have looked into the present IDE suspend/resume, but they don't appear to
be called in S3 mode (my printk in ide-disk.c do_idedisk_resume() didn't
happen).  I kludged the piix.c file, adding a suspend and resume routine to
PCI device structure (which gets called).  In the resume I forced a call to
piix_config_drive_xfer_rate(), which does get the disk back to being useable
again, but I know this is in NO way the correct method :)

 Any info on direction or other help would be appreciated.


  Mike Faraoni



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S3 Resume working, but IDE disk hung

[Alan Cox]

On Fri, 2002-10-04 at 16:02, Faraoni, Michael wrote:
>  I have looked into the present IDE suspend/resume, but they don't appear to
> be called in S3 mode (my printk in ide-disk.c do_idedisk_resume() didn't
> happen).  I kludged the piix.c file, adding a suspend and resume routine to
> PCI device structure (which gets called).  In the resume I forced a call to
> piix_config_drive_xfer_rate(), which does get the disk back to being useable
> again, but I know this is in NO way the correct method :)

When you come back you want to reconfigure the controller and drive,
then possibly need to wake the drive. The reconfiguration may well need
more than a retune - you might for example have lost the multimode
settings, the host protected area etc. I would argue that you pretty
much need to reinitialize the controller - you don't know if a drive
changed, the cables changed etc from S4 and S3 needs most of the same
support anyway.

You are certainly on the right track and its a sane starting point.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S3 Resume working, but IDE disk hung

[Andre Hedrick]

Prior to suspend one needs to :

	block all new coming requests.
	flush cache and wait for return.
	disable DMA, and switch to PIO 0.
	then S3 and S4 should/will be stable.

Resume requires calling :

	"do_reset()"
	for (;;)
		if ((check_power()) == active)
			break;
	"piix_config_drive_xfer_rate()" 
	unblock request pathway.

Cheers,

Andre Hedrick
LAD Storage Consulting Group


On 4 Oct 2002, Alan Cox wrote:

> On Fri, 2002-10-04 at 16:02, Faraoni, Michael wrote:
> >  I have looked into the present IDE suspend/resume, but they don't appear to
> > be called in S3 mode (my printk in ide-disk.c do_idedisk_resume() didn't
> > happen).  I kludged the piix.c file, adding a suspend and resume routine to
> > PCI device structure (which gets called).  In the resume I forced a call to
> > piix_config_drive_xfer_rate(), which does get the disk back to being useable
> > again, but I know this is in NO way the correct method :)
> 
> When you come back you want to reconfigure the controller and drive,
> then possibly need to wake the drive. The reconfiguration may well need
> more than a retune - you might for example have lost the multimode
> settings, the host protected area etc. I would argue that you pretty
> much need to reinitialize the controller - you don't know if a drive
> changed, the cables changed etc from S4 and S3 needs most of the same
> support anyway.
> 
> You are certainly on the right track and its a sane starting point.
> 
> 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S3 Resume working, but IDE disk hung

[Pavel Machek]

Hi!

[Note, you should look at the patch "to prevent data corruption". It
could do the trick. At least it should be good as a base.

> Prior to suspend one needs to :
> 
> 	block all new coming requests.
> 	flush cache and wait for return.
> 	disable DMA, and switch to PIO 0.

Why would you want to switch off DMA and go PIO 0?

As long as DMA is not happening (that is not disabled, we just don't
ask drive to do it), you should be fine.

> Resume requires calling :
> 
> 	"do_reset()"
> 	for (;;)
> 		if ((check_power()) == active)
> 			break;
> 	"piix_config_drive_xfer_rate()" 
> 	unblock request pathway.

You don't need to block/unblock request pathways. kernel/suspend.c takes care of that.

									Pavel
-- 
I'm pavel-7aPAsKgELzg@public.gmane.org "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss-q33YXrgyAoMgsBAKwltoeQ@public.gmane.org


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S3 Resume working, but IDE disk hung

[Andre Hedrick]

On Sun, 6 Oct 2002, Pavel Machek wrote:

> Hi!
> 
> [Note, you should look at the patch "to prevent data corruption". It
> could do the trick. At least it should be good as a base.
> 
> > Prior to suspend one needs to :
> > 
> > 	block all new coming requests.
> > 	flush cache and wait for return.
> > 	disable DMA, and switch to PIO 0.
> 
> Why would you want to switch off DMA and go PIO 0?

Because it is a known state when we drop out of the driver.
99% of the failures of ACPI (please read the fine print, where it requires
discrete access to "task file registers") is not knowing where or what
stated the device and driver is set in.

The reality is it does not matter if it is in PIO 0 to the hardware, but
setting the values in the kernel so it knows what to do is critical.

> As long as DMA is not happening (that is not disabled, we just don't
> ask drive to do it), you should be fine.
                       ^^^^^^^^^^^^^^^^^^

Should does not cut it, period.
Either you are or are not correct.
Guessing in the middle is unacceptable to me.
Call me Andre "The Anal Retentive Dude Wielding a SPEC" Hedrick, but
building from the top down is how and why the driver got in the mess it
is/was today.

> > Resume requires calling :
> > 
> > 	"do_reset()"
> > 	for (;;)
> > 		if ((check_power()) == active)
> > 			break;
> > 	"piix_config_drive_xfer_rate()" 
> > 	unblock request pathway.
> 
> You don't need to block/unblock request pathways. kernel/suspend.c
> takes care of that.

Really, try sending a command to a drive when it is not ready.  Try send
it to after a sleep, and watch it eat the command and hang the bus.

It really seems like you can not or will not listen to real-documented
logical concerns.  So please do as you wish and push it through, it does
not bother me.  It will give me another chance to blast Linus and deflect
it to you at the next Summit when people start badgering me again over the
order of operations for suspend.  Sheesh, even Andy Grover at the 2.5
summit in San Jose admitted I was correct in the model.

I am now out of the issue directly, please send to Alan Cox, and I will
address is concerns about the issues.

Cheers,

Andre Hedrick
LAD Storage Consulting Group



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S3 Resume working, but IDE disk hung

[Pavel Machek]

Hi!

> > [Note, you should look at the patch "to prevent data corruption". It
> > could do the trick. At least it should be good as a base.
> > 
> > > Prior to suspend one needs to :
> > > 
> > > 	block all new coming requests.
> > > 	flush cache and wait for return.
> > > 	disable DMA, and switch to PIO 0.
> > 
> > Why would you want to switch off DMA and go PIO 0?
> 
> Because it is a known state when we drop out of the driver.
> 99% of the failures of ACPI (please read the fine print, where it requires
> discrete access to "task file registers") is not knowing where or what
> stated the device and driver is set in.
> 
> The reality is it does not matter if it is in PIO 0 to the hardware, but
> setting the values in the kernel so it knows what to do is critical.
> 
> > As long as DMA is not happening (that is not disabled, we just don't
> > ask drive to do it), you should be fine.
>                        ^^^^^^^^^^^^^^^^^^
> 
> Should does not cut it, period.
> Either you are or are not correct.

Which spec does specify it needs to be in PIO0? I don't want to read
between the lines.

Actually, working around broken ACPI is probably good idea. And as
Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> shown, such broken ACPI exists.

> > > Resume requires calling :
> > > 
> > > 	"do_reset()"
> > > 	for (;;)
> > > 		if ((check_power()) == active)
> > > 			break;
> > > 	"piix_config_drive_xfer_rate()" 
> > > 	unblock request pathway.
> > 
> > You don't need to block/unblock request pathways. kernel/suspend.c
> > takes care of that.
> 
> Really, try sending a command to a drive when it is not ready.  Try send
> it to after a sleep, and watch it eat the command and hang the bus.

You can't send a command to the drive when not ready, because there's
noone there to generate request. If there is one, you have bigger
problems than that.

> It really seems like you can not or will not listen to real-documented
> logical concerns.  So please do as you wish and push it through, it does
> not bother me.  It will give me another chance to blast Linus and
> deflect

Okay. What's in there in 2.5.41 is fine with me (at least it does not
eat disks any more). Doing while check_power() and going PIO 0 seems
like good idea, and if someone wishes to add it, good luck for
him. blocking/unblocking request pathways is bad idea and is not
needed.
								Pavel
-- 
When do you have heart between your knees?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: S3 Resume working, but IDE disk hung

[Faraoni, Michael]

All,

 I took Andre's advice and implemented the reset(), wait for completion,
then call piix_config_drive_xfer_rate().  This gets the disk back into a
sane state and is useable (but code isn't yet ready for primetime:).  I had
to create a new reset function in ide-iops.c that didn't set a timer,
instead I pulled logic from do_reset1() and reset_pollfunc(), resetting the
disk and just looping until reset is seen complete.  The fix Pavel put in
2.5.41, doesn't fix IDE disk after resume (at least on my system). 

 FYI - The do_reset1()/reset_pollfunc() have a bug that panics the kernel in
kernel/timer.c:112 (check for timer pending) that isn't related to
suspend/resume.  Doing a "hdparm -w /dev/hda" will cause the panic.

 The suspend/resume in the piix.c is registered in PCI device structure and
called through Device_Resume(), it would be nicer if the upper IDE layers
would coordinate these activities.  When we resume from S3, we know that all
IDE interfaces/drives need to reset and re-initialized. The IDE layer could
call init functions again (of course want to avoid re-registering and a lot
of initialization code is prefixed with __init) or reset devices.   Any
thoughts on this approach, where to start, am I way off, etc.?  

 Also, in trying to get the serial port working after resume, I noticed that
routines registered with pm_register() never get called on an S3 transition
(only on S4 suspend to disk).  I added a call to pm_send_all(SUSPEND) and
pm_send_all(RESUME) in drivers/acpi/sleep.c: acpi_suspend().  This caused
serial port suspend/resume functions to now be called (of course serial port
didn't quite come back, it seems to receive characters but not transmit
any?) and my IDE fix gets run twice.  Are these two suspends (S3 & S4)
suppose to play better together?  What is the relationship with kernel/pm.c
stuff and acpi/sleep.c stuff?

 I apologize if any of these questions have already been answered or debated
before.

 Thanks for help,

  Mike


> -----Original Message-----
> From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org]
> Sent: Tuesday, October 08, 2002 4:21 PM
> To: Andre Hedrick
> Cc: Ducrot Bruno; Alan Cox; Faraoni, Michael;
> acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] S3 Resume working, but IDE disk hung
> 
> 
> Hi!
> 
> > > [Note, you should look at the patch "to prevent data 
> corruption". It
> > > could do the trick. At least it should be good as a base.
> > > 
> > > > Prior to suspend one needs to :
> > > > 
> > > > 	block all new coming requests.
> > > > 	flush cache and wait for return.
> > > > 	disable DMA, and switch to PIO 0.
> > > 
> > > Why would you want to switch off DMA and go PIO 0?
> > 
> > Because it is a known state when we drop out of the driver.
> > 99% of the failures of ACPI (please read the fine print, 
> where it requires
> > discrete access to "task file registers") is not knowing 
> where or what
> > stated the device and driver is set in.
> > 
> > The reality is it does not matter if it is in PIO 0 to the 
> hardware, but
> > setting the values in the kernel so it knows what to do is critical.
> > 
> > > As long as DMA is not happening (that is not disabled, we 
> just don't
> > > ask drive to do it), you should be fine.
> >                        ^^^^^^^^^^^^^^^^^^
> > 
> > Should does not cut it, period.
> > Either you are or are not correct.
> 
> Which spec does specify it needs to be in PIO0? I don't want to read
> between the lines.
> 
> Actually, working around broken ACPI is probably good idea. And as
> Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> shown, such broken ACPI exists.
> 
> > > > Resume requires calling :
> > > > 
> > > > 	"do_reset()"
> > > > 	for (;;)
> > > > 		if ((check_power()) == active)
> > > > 			break;
> > > > 	"piix_config_drive_xfer_rate()" 
> > > > 	unblock request pathway.
> > > 
> > > You don't need to block/unblock request pathways. kernel/suspend.c
> > > takes care of that.
> > 
> > Really, try sending a command to a drive when it is not 
> ready.  Try send
> > it to after a sleep, and watch it eat the command and hang the bus.
> 
> You can't send a command to the drive when not ready, because there's
> noone there to generate request. If there is one, you have bigger
> problems than that.
> 
> > It really seems like you can not or will not listen to 
> real-documented
> > logical concerns.  So please do as you wish and push it 
> through, it does
> > not bother me.  It will give me another chance to blast Linus and
> > deflect
> 
> Okay. What's in there in 2.5.41 is fine with me (at least it does not
> eat disks any more). Doing while check_power() and going PIO 0 seems
> like good idea, and if someone wishes to add it, good luck for
> him. blocking/unblocking request pathways is bad idea and is not
> needed.
> 								Pavel
> -- 
> When do you have heart between your knees?
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: S3 Resume working, but IDE disk hung

[Alan Cox]

On Wed, 2002-10-09 at 15:35, Faraoni, Michael wrote:
>  The suspend/resume in the piix.c is registered in PCI device structure and
> called through Device_Resume(), it would be nicer if the upper IDE layers
> would coordinate these activities.  When we resume from S3, we know that all

The pci layer may well be the right place to do this anyway. It will
bring the various layers up for you. There is also a good argument that
you want to provide your code as

      ide_pci_generic_resume()

in pci-setup or ide-lib and call that from the drivers, because someone
will eventually have a controller that needs different fixes. Making the
driver do the call to the library code makes that easy. The reverse
causes much pain




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf