Re: Suspend to memory is freezing my machine

[Jacek Luczak <difrost.kernel@gmail.com>]

Robert Hancock pisze:
> Jacek Luczak wrote:
>> Robert Hancock pisze:
>>> Jacek Luczak wrote:
>>>> Rafael J. Wysocki pisze:
>>>>> On Sunday, 4 of May 2008, Zdenek Kabelac wrote:
>>>>>> Hello
>>>>> Hi,
>>>>>
>>>>>> With recent 2.6.25 & 2.6.26-rc1 git (around 1 week) I get
>>>>>> occasionally
>>>>>> complete freeze of my T61 during suspend. (dual core, 2GB).
>>>>> How reproducible is this?
>>>>>
>>>>>> I'm running kernel with no_console_suspend - but all I can see is
>>>>>> blinking cursor on an empty screen - thus even when I run kernel with
>>>>>> most debug options turned on, I can't pass more details so far.  I
>>>>>> run
>>>>>> suspend with with SD card in - so maybe some update in the MMC driver
>>>>>> might be responsible for this ?
>>>>>>
>>>>>> Also - I think that option no_console_suspend doens't work
>>>>>> correctly -
>>>>>> as many times with suspend I do not see any log message on my console
>>>>>> screen. However sometimes the log is shown.
>>>>> It would be helpful if you could verify if:
>>>>>
>>>>> (1) The problem occurs without no_console_suspend.
>>>>> (2) The problem occurs without the SD card.
>>>>>
>>>> Hi Rafael,
>>>>
>>>> same problem here, although I was able to resume system (it's
>>>> basically Intel
>>>> machine) , but it was unusable - I was able to switch between
>>>> terminals and see
>>>> output from kernel. So there was:
>>>>     - Disabling irq #19;
>>>>     - some kind of lock spinning on disk:
>>>> IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA
>>>> Storage
>>>> Controller IDE (rev 02)
>>>>     but I can't provide more output of that lock now - no sign in logs.
>>>>
>>>> I've made some successful suspend/resume all without sound card active
>>>> without
>>>> problem. Those appear with sound card active, but I must take closer
>>>> look - will
>>>> send info later.
>>> Can you post your dmesg and /proc/interrupts output from normal bootup ?
>>
>> Sure I can ;)
>>
>> 1) /proc/interrupts
>>
>>            CPU0       CPU1
>>   0:   11846981          0   IO-APIC-edge      timer
>>   1:      30098          0   IO-APIC-edge      i8042
>>   8:          3          0   IO-APIC-edge      rtc
>>   9:         13          0   IO-APIC-fasteoi   acpi
>>  12:    1776540          0   IO-APIC-edge      i8042
>>  14:         39          0   IO-APIC-edge      ata_piix
>>  15:          0          0   IO-APIC-edge      ata_piix
>>  16:      54570      44642   IO-APIC-fasteoi   i915@pci:0000:00:02.0
>>  17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
>>  18:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
>>  19:      98243          0   IO-APIC-fasteoi   ata_piix, uhci_hcd:usb5
>>  21:    1650574          0   IO-APIC-fasteoi   HDA Intel
>>  23:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1,
>> uhci_hcd:usb2
>> 220:      14263          0   PCI-MSI-edge      iwl3945
>> 221:    1166041    1333296   PCI-MSI-edge      eth0
>> NMI:          0          0   Non-maskable interrupts
>> LOC:    1104887    7534969   Local timer interrupts
>> RES:     633378     701351   Rescheduling interrupts
>> CAL:         16      28315   function call interrupts
>> TLB:       1721       2620   TLB shootdowns
>> TRM:          0          0   Thermal event interrupts
>> SPU:          0          0   Spurious interrupts
>> ERR:          0
>> MIS:          0
>>
>> 2) dmesg can here -> http://212.109.128.251/~difrost/linux-next/dmesg.log
>> 3) Kernel:
>> Linux difrost 2.6.25-07422-gb66e1f1-dirty #14 SMP Fri May 2 22:04:17
>> CEST 2008
>> i686 i686 i386 GNU/Linux
>> It's marked dirty because due to http://lkml.org/lkml/2008/5/2/405
>> patch applied.
>>
>> -Jacek
>>
> 
> Well, if IRQ 19 got disabled, that's your SATA controller, so resume
> likely isn't going to work. Could be a libata problem? CCing linux-ide.

Yep, I know, that's why I pointed that out. Irq was disabled somehow in suspend
or resume process.

> BTW, if your BIOS offers an option to enable AHCI on your SATA
> controller then that would be a more optimal configuration (could get
> NCQ support), but that is an aside.

With AHCI I've got pretty bad timings (and I don't really know why!):

[root|20:49|~]$ cat sda_ahci_t

/dev/sda:
 Timing cached reads:   1560 MB in  2.00 seconds = 780.51 MB/sec
 Timing buffered disk reads:  102 MB in  3.02 seconds =  33.74 MB/sec
[root|20:49|~]$ cat sda_piix_t

/dev/sda:
 Timing cached reads:   1544 MB in  2.00 seconds = 772.35 MB/sec
 Timing buffered disk reads:  134 MB in  3.04 seconds =  44.05 MB/sec

-Jacek