Bug 11178

Created attachment 17027 [details]
Dmesg including errors during resume

Created attachment 17028 [details]
Output of lspci

lspci may help identify my chipset.

Created attachment 17029 [details]
dmesg showing errors after suspend to ram

The same errors also occur on resume from STR.  Here's a dmesg of that.  I booted with init=/bin/bash this time, so this log may be less noisy.  I used s2ram --force --acpi_sleep=3.

(My machine can't be whitelisted by s2ram because it's DMI identification is uselessly generic).

Aha, a lucky guess.

The commit responsible is 24920c8a6358bf5532f1336b990b1c0fe2b599ee.
("AHCI: speed up resume").

Sorry for slandering AHCI; that's not it.  I tried to test using s2ram again and I must have got the options wrong.  "speed up resume" is not the problem.

(In reply to comment #5)
> Sorry for slandering AHCI; that's not it.  I tried to test using s2ram again
> and I must have got the options wrong.  "speed up resume" is not the problem.

I assume this means the problem occurs, but is not related to the "AHCI: speed up resume" commit.

Well, nothing obvious comes to mind and I'm unable to reproduce this.

The problem happens, but not in that commit.  This is the right (or rather, wrong :-) commit:

ce6fce4295ba727b36fdc73040e444bd1aae64cd is first bad commit
commit ce6fce4295ba727b36fdc73040e444bd1aae64cd
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Fri Jul 25 15:42:58 2008 -0600

    PCI MSI: Don't disable MSIs if the mask bit isn't supported

    David Vrabel has a device which generates an interrupt storm on the INTx
    pin if we disable MSI interrupts altogether.  Masking interrupts is only
    a performance optimisation, so we can ignore the request to mask the
    interrupt.

    Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Since the above commit makes a difference, my hardware must trip the "mask bit
isn't supported" case.

$ grep MSI /proc/interrupts
222:        225          0   PCI-MSI-edge      ahci
$

This MSI interrupt stuff is a mystery to me.  I guess something breaks the
assertion that masking interrupts was only a performance optimisation...

Oops.  I forgot that there is something different about the second hard drive. 
The second one is actually a PATA drive (the other one is SATA).  Sorry, that
was a stupid omission.

So this is almost certainly a bad interaction between ahci and ata_piix.

Sorry, another mistake.

The drive that fails is not the "second" drive, the PATA one.  The failure is in the original _SATA_ drive.  The original drive became "sdb" after I added the PATA one.

# PATA devices - sda, sr0
$ ls /sys/bus/pci/drivers/ata_piix/*/host*/target*/*:*/
/sys/bus/pci/drivers/ata_piix/0000:00:1f.1/host0/target0:0:0/0:0:0:0/:
block:sda  device_blocked    generic        ioerr_cnt      model        queue_type  scsi_device:0:0:0:0  scsi_level  timeout  vendor
bus        driver            iocounterbits  iorequest_cnt  power        rescan      scsi_disk:0:0:0:0    state       type
delete     evt_media_change  iodone_cnt     modalias       queue_depth  rev         scsi_generic:sg0     subsystem   uevent

/sys/bus/pci/drivers/ata_piix/0000:00:1f.1/host0/target0:0:1/0:0:1:0/:
block:sr0  device_blocked    generic        ioerr_cnt      model        queue_type  scsi_device:0:0:1:0  state      type
bus        driver            iocounterbits  iorequest_cnt  power        rescan      scsi_generic:sg1     subsystem  uevent
delete     evt_media_change  iodone_cnt     modalias       queue_depth  rev         scsi_level           timeout    vendor

# SATA devices - sdb
$ ls /sys/bus/pci/drivers/ahci/*/host*/target*/*:*/
block:sdb  device_blocked    generic        ioerr_cnt      model        queue_type  scsi_device:2:0:0:0  scsi_level  timeout  vendor
bus        driver            iocounterbits  iorequest_cnt  power        rescan      scsi_disk:2:0:0:0    state       type
delete     evt_media_change  iodone_cnt     modalias       queue_depth  rev         scsi_generic:sg2     subsystem   uevent

Created attachment 17043 [details]
Proposed fix

Gotcha.

Matthew's original commit missed a second piece of logic that does the same thing on resume.  The attached patch fixes this on my computer.

Hopefully Pavel's boot-time suspend self-test will get this sort of thing noticed earlier :-).

Handled-By : Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=17043&action=view

I'm not sure what is meant by Handled-By.  I'm still hoping Matthew will accept ownership of this bug (and my proposed patch).

I tried correcting the Product/Component to Drivers/PCI, but Bugzilla said I had to change the Version to 2.5 first :-(.

Prod me if there's anything more I can do.

Handled-By means that you have identified the problem and proposed a patch to fix it.

*** Bug 11232 has been marked as a duplicate of this bug. ***

I meet a similar problem on my IBM T61. 
it report Input/output error. after back from resume in memory. 

the "proposed fix" patch works for me. So hope it can be merged in upstream. 

Solves it for me, too.

I couldn't resume on my system either; this fixed it.  Surprised the fix didn't find its way into RC2 ...

The fix looks good, I just want to get willy's ack before merging it.  I'll ask Linus to pull it asap after that...

Thanks,
Jesse

Fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=abad2ec98f2ef357d62026cbc3989dabf33f2435

*** Bug 11283 has been marked as a duplicate of this bug. ***

*** Bug 11214 has been marked as a duplicate of this bug. ***

I think I've got this same bug on an Acer Aspire 4350, but both of the Ubuntu 2.6.27-9-generic and the 2.6.28-rc8 kernel.org kernels I've built have this patch in them yet I still see this problem.

I will post some attachments with the particulars of my machine.

I find that if I boot either of these kernels with pci=nomsi, then the problem does not occur.

Created attachment 19394 [details]
dmesg from suspend/resume without pci=nomsi

This is the dmesg after a resume where I have not booted the kernel with pci=nomsi and the disk is not working.

Created attachment 19395 [details]
lspci from acer aspire 4350

lspci from Acer Aspire 4350

Created attachment 19396 [details]
dmesg from suspend/resume *with* pci=nomsi

Successful (albeit slow) resume when using pci=nomsi.