Re: Suspend to memory is freezing my machine

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

Robert Hancock pisze:
>>>>>>>> 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
>>
>> Here's the latest report (all on latest git):
>>     1) I've switched to AHCI mode and suspend/resume works OK (because
>> SATA
>> controller irq is not disabled).
>>
>>     2) now /proc/interrupts look like that:
>>            CPU0       CPU1
>>   0:     110708          0   IO-APIC-edge      timer
>>   1:       4008          0   IO-APIC-edge      i8042
>>   8:          3          0   IO-APIC-edge      rtc
>>   9:      15091          0   IO-APIC-fasteoi   acpi
>>  12:      77467          0   IO-APIC-edge      i8042
>>  14:         44          0   IO-APIC-edge      ata_piix
>>  15:          0          0   IO-APIC-edge      ata_piix
>>  16:          0          0   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:     100001          0   IO-APIC-fasteoi   uhci_hcd:usb5
>>  21:        282          0   IO-APIC-fasteoi   HDA Intel
>>  23:          1          0   IO-APIC-fasteoi   ehci_hcd:usb1,
>> uhci_hcd:usb2
>> 219:        858          0   PCI-MSI-edge      iwl3945
>> 220:       8616          0   PCI-MSI-edge      eth0
>> 221:       6423          0   PCI-MSI-edge      ahci
>> NMI:          0          0   Non-maskable interrupts
>> LOC:      15777      64510   Local timer interrupts
>> RES:       9045      24560   Rescheduling interrupts
>> CAL:         30      28255   function call interrupts
>> TLB:        341        145   TLB shootdowns
>> TRM:          0          0   Thermal event interrupts
>> SPU:          0          0   Spurious interrupts
>> ERR:          0
>> MIS:          0
>>
>>     3) The IRQ #19 remains disabled after resume and produce:
>> irq 19: nobody cared (try booting with the "irqpoll" option)
>> Pid: 13, comm: kacpi_notify Not tainted
>> 2.6.26-rc1-07561-gafa26be-dirty #16
>>  [<c013ea27>] __report_bad_irq+0x24/0x69
>>  [<c013ea2e>] __report_bad_irq+0x2b/0x69
>>  [<c013ec25>] note_interrupt+0x1b9/0x210
>>  [<c013e36c>] handle_IRQ_event+0x1a/0x3f
>>  [<c013f195>] handle_fasteoi_irq+0x84/0xa2
>>  [<c0104fde>] do_IRQ+0x4f/0x65
>>  [<c01034ff>] common_interrupt+0x23/0x28
>>  [<c013007b>] timekeeping_resume+0x9b/0x127
>>  [<c020b090>] acpi_os_read_port+0x29/0x44
>>  [<c02177c9>] acpi_hw_register_read+0x61/0x119
>>  [<c020f76e>] acpi_ev_fixed_event_detect+0x2a/0xa0
>>  [<c021001a>] acpi_ev_sci_xrupt_handler+0x9/0x17
>>  [<c020b053>] acpi_irq+0xb/0x1f
>>  [<c013e36c>] handle_IRQ_event+0x1a/0x3f
>>  [<c013f181>] handle_fasteoi_irq+0x70/0xa2
>>  [<c0104fde>] do_IRQ+0x4f/0x65
>>  [<c020b623>] acpi_os_execute_deferred+0x0/0x25
>>  [<c01034ff>] common_interrupt+0x23/0x28
>>  [<c020b623>] acpi_os_execute_deferred+0x0/0x25
>>  [<c020b0b8>] acpi_os_write_port+0xd/0x2c
>>  [<c020b640>] acpi_os_execute_deferred+0x1d/0x25
>>  [<c01290fa>] run_workqueue+0x69/0xda
>>  [<c0129221>] worker_thread+0xb6/0xc2
>>  [<c012bca6>] autoremove_wake_function+0x0/0x2d
>>  [<c012916b>] worker_thread+0x0/0xc2
>>  [<c012ba42>] kthread+0x38/0x5d
>>  [<c012ba0a>] kthread+0x0/0x5d
>>  [<c010370f>] kernel_thread_helper+0x7/0x10
>>  =======================
>> handlers:
>> [<c027d100>] (usb_hcd_irq+0x0/0x53)
>> Disabling IRQ #19
> 
> Hmm, so either it's the SATA controller still generating that IRQ even
> when it's in AHCI mode, or else it's USB that's the real problem..

I thing your are right here. I've made some basic tests. Removed USB support
form kernel and then suspend/resume with new one. There were no disabled irq
printouts as the one above. But then I've started new kernel compilation (back
with USB support and CONFIG_USB_SUSPEND=y) and suddenly Irq 221 was disabled -
the ,,nobody cared'' error was printed out. Kernel was trying to reset it but it
stacked (I will try to catch those messages).

I will make some tests on second system (I wouldn't like to break primary, as
while kernel is trying to bring back disk to live, the xfs errors are printed -
mainly failed writes).

-Jacek