Snore: BUG in ide-disk on suspend

Snore: BUG in ide-disk on suspend

[P. Christeas]

I don't feel I am the one that should mess with the ide part (I could break a 
lot of important things). However, sleeping has failed many times because of 
ide. 

drivers/ide/ide-disk.c: (around 1557)
        printk(KERN_INFO "suspending: %s ", drive->name);
        do_idedisk_standby(drive);
        drive->blocked = 1;

	BUG_ON (HWGROUP(drive)->handler);

AFAIK handler is set whenever an irq is being handled (correct me if I'm 
wrong). ide irqs are very often on the system and may happen between the 
actual call to 'ide_do_cmd' (called by do_idedisk_standby) and the 
"blocked=1" line. 
Setting a strict lock may deadlock the system pretty hard! Would the 
"blocked=1" line break the do_idedisk_standby? Does "blocked" really stop 
subsequent disk activity?
Or, alternatively should we setup a mechanism (spinlock?) to cause the 
do_ide_standby to wait until pending requests-data finishes?

Kernels: 2.5.55-58
ACPI: the one in those. Currently: 20030109
System: HP Omnibook Xe3 GC, Disk: IBM DeskStar in 32bit mode.

Thanks.




-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en

Re: Snore: BUG in ide-disk on suspend

[Pavel Machek]

Hi!

> drivers/ide/ide-disk.c: (around 1557)
>         printk(KERN_INFO "suspending: %s ", drive->name);
>         do_idedisk_standby(drive);
>         drive->blocked = 1;
> 
> 	BUG_ON (HWGROUP(drive)->handler);
> 
> AFAIK handler is set whenever an irq is being handled (correct me if I'm 
> wrong). ide irqs are very often on the system and may happen between the 
> actual call to 'ide_do_cmd' (called by do_idedisk_standby) and the 
> "blocked=1" line. 

blocked=1 is basically sanity check; not critical.

Userland should not be alive at this point, so
there should be noone to ask for work to do,
and when there's no work, there should be no
interrupts.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Snore: BUG in ide-disk on suspend

[Andre Hedrick]

On Mon, 20 Jan 2003, Pavel Machek wrote:

> Hi!
> 
> > drivers/ide/ide-disk.c: (around 1557)
> >         printk(KERN_INFO "suspending: %s ", drive->name);
> >         do_idedisk_standby(drive);
> >         drive->blocked = 1;
> > 
> > 	BUG_ON (HWGROUP(drive)->handler);
> > 
> > AFAIK handler is set whenever an irq is being handled (correct me if I'm 
> > wrong). ide irqs are very often on the system and may happen between the 
> > actual call to 'ide_do_cmd' (called by do_idedisk_standby) and the 
> > "blocked=1" line. 
> 
> blocked=1 is basically sanity check; not critical.
> 
> Userland should not be alive at this point, so
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
           !!!!!!

Pavel,

This very point of uncertain state of the driver really bugs me.


> there should be noone to ask for work to do,

Noone == ??

SMI events by the BIOS or anything ...

> and when there's no work, there should be no
> interrupts.

If you say should and you get on report back that it is not ...
We are in deep crap ...

Also never trust a spec unless you were there to write it and then think
twice and do it once.

The "assume" kills me.

Cheers,

Andre Hedrick
LAD Storage Consulting Group



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Snore: BUG in ide-disk on suspend

[P. Christeas]

> > drivers/ide/ide-disk.c: (around 1557)
> >         printk(KERN_INFO "suspending: %s ", drive->name);
> >         do_idedisk_standby(drive);
> >         drive->blocked = 1;
> >
> > 	BUG_ON (HWGROUP(drive)->handler);
> >
> > AFAIK handler is set whenever an irq is being handled (correct me if I'm
> > wrong). ide irqs are very often on the system and may happen between the
> > actual call to 'ide_do_cmd' (called by do_idedisk_standby) and the
> > "blocked=1" line.
>
> blocked=1 is basically sanity check; not critical.
>
> Userland should not be alive at this point, so
> there should be noone to ask for work to do,
> and when there's no work, there should be no
> interrupts.

noone:  I can thing of 2 already:
1. hw interrupts: Is there a case that a device (even IDE itself, having some 
result from previous transaction) will cause a system-land series of 
interrupts?
2. That devious 'printk' ! The syslog has to write to the log..

After little more testing, I noticed that the offending IRQ is more probable 
if a cdrom is in my drive (secondary IDE bus, when mounted it gets even more 
likely).
For some reason[1] 2.5.57 doesn't seem[2] to have that bug.

Thanks.

[1] after a rapid scan through the suspend code, I haven't noticed any changes 
since then. However, any unrelated event could cause a disk activity..

[2] 2.5.58 fails at 1st or 2nd (in a single boot) time I attempt to sleep it. 
2.5.57 has run for weeks w/o trouble.



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com