Hello 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). 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. Zdenek --
Same here. Suspend to ram crashes on resume starting in 2.6.25 (didn't test 2.6.25-rc in my production system). Because this isn't 100% reproducible bisecting may return false negatives. --
Of course I've planned to bisect for the lost console logging - maybe tomorrow. The crash in suspend is pretty random - I've never got the lock at my will - usually it happens when I completely do not expect it ;) Zdenek --
Try switching consoles with alt-arrows... s2ram plays with console switches so messages may be there but on other console. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
No change - logging is simply not visible anywhere - if there will be some time I could probably bisect and find which commit randomised console logging. Zdenek --
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. Thanks, Rafael --
Hello Rafael The problem happens still even with -rc3. Now I've an update: Usually I've to run the machine for couple hours to actually be able to hit this lock. (Usually after a day work when I want to leave) I've also noticed that when I run the suspend after the reboot I usually cannot see the suspend freeze - mostly because either the I've figured out, it was caused by some weird Fedora setting, so SD card or no_console_suspend option doesn't matter This is what I've seen as the last thing on the screen when deadlock appeared this time: (no SD card inserted) ==== Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep drm card0: class suspend drm_sysfs_suspend ACPI: PCI interrupt for device 0000:00:02.0 disabled ==== and this is what usually follows when the suspend works correctly ==== sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device 0000:15:00.2 disabled ACPI: PCI interrupt for device 0000:00:1f.1 disabled ... lcpci: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21) 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03) Here is also the grep from my messages log for 'hash matches device' (gathered over some time) (Having PM_TRACE_RTC=y in the .config) device:02 device:02 0000:00:1c.1:pcie03 0000:00:1c.0:pcie02 device:0a cooling_device1 0000:15:00.1 device:07 tty47 mcelog 0000:00:02.1 device:0c 0000:0d tty53 tty55 device:22 target0:0:0 device:03 PNP0C02:00 00:04 0000:00:1c.0:pcie00 sda PNP0C0F:02 tty47 mcelog 0000:00:02.1 ram7 device:13 device:04 fbcon From this list it looks pretty random :( - so I'll keep an eye if the deadlock appears alway in the same place. But if you have any idea what kind of debuging would help to find the prob...
Hm, what kind of graphics adapter is there in your box? Rafael --
After some more checking - I guess this information actually is not useful at all :(. It looks like even when the suspend is succesful - the line: ACPI: PCI interrupt for device 0000:00:02.0 disabled is alway the last one visible. I'll try to get figure out a better way how to invoke the lock. And my graphics adapter is: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller]) Zdenek --
If you use s2ram, please check if "echo mem > /sys/power/state" works instead. Thanks, Rafael --
The problem occurs also with plain echo 'mem' - I've already checked before. Just resently I've discovered that actually I've had some serious problem with CONFIG_DEBUG_PAGEALLOC option. Unsure if this thing could be related to my deadlocking problem during suspend - I'll watch, if the freeze will be still ocurring even without this option. I'll make probably a separate post about my debug option problem. Zdenek --
Hello It looks like from the time I've disabled CONFIG_DEBUG_PAGEALLOC option I've not seen a single freeze during the suspend - I'll continue to watch this - but I guess it's the key part of my problem. Zdenek --
After some more checking - I guess this information actually is not useful at all :(. It looks like even when the suspend is succesful - the line: ACPI: PCI interrupt for device 0000:00:02.0 disabled is alway the last one visible. I'll try to get figure out a better way how to invoke the lock. And my graphics adapter is: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller]) Zdenek --
Unfortunately not at my wish - usually in the least expected moment. (Actually I've once even put notebook into the bag without checking its sleeping :( Will keep an eye on this - I usually keep SD card in. Zdenek --
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. -Jacek --
| Pardo | Re: pthread_create() slow for many threads; also time to revisit 64b context switc... |
| Paul Jackson | Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses) |
| Srivatsa Vaddagiri | Re: [PATCH, RFC] reimplement flush_workqueue() |
| Peter Zijlstra | Re: Btrfs v0.16 released |
git: | |
| Giuseppe Bilotta | Re: gitweb and remote branches |
| Miklos Vajna | [rfc] git submodules howto |
| JD Guzman | C# Git Implementation |
| Junio C Hamano | Re: [PATCH] fix parallel make problem |
| Richard Stallman | Real men don't attack straw men |
| Steve B | SSH brute force attacks no longer being caught by PF rule |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Marius ROMAN | 1440x900 resolution problem |
| Tomasz Grobelny | [PATCH 0/5] [DCCP]: Queuing policies |
| Dushan Tcholich | Re: ksoftirqd high cpu load on kernels 2.6.24 to 2.6.27-rc1-mm1 |
| John Heffner | Re: A Linux TCP SACK Question |
| Denys Fedoryshchenko | Re: Could you make vconfig less stupid? |
