| Summary: | INFO: possible circular locking dependency detected (ext4_evict_inode &sb->s_type->i_mutex_key vs &mm->mmap_sem) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | koukou73gr | ||||||||||
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> | ||||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 15 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-03-17 16:31:36 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Attachments: |
|
||||||||||||
Created attachment 502137 [details]
dmesg messages after thawing.
Does this still happen with the latest 2.6.40.x F15 kernel? Sort of... Just tested with 2.6.40.4-5.fc15.x86_64.debug today, booted, hibernated, resumed, hibernated and resumed again. I got an INFO trace for a possible deadlock after the first resume, see attached dmesg. I've been testing even with the 3.x series, no matter what kernel version so far, after 3-4 hibernate/resume cycles my system will echo INFO/BUG traces and either fail to hibernate again, crash upon next resume, fail to bring up wired or wireless network cards and generally come to a state where I am forced to make a clean boot. Pretty bad for a laptop with no exotic hardware whatsoever :( Thanks for looking into this. Created attachment 525946 [details]
dmesg, 2.6.40.4-5.fc15
And then again, after third hibernate/resume cycle, there was an INFO trace logged during hibernation. Attached dmesg picks up exaclty where the previous one left off, this is the same clean boot cycle. Created attachment 526029 [details]
dmesg, 2.6.40.4-5.fc15, continued
this looks familiar. I think this may have been fixed in latest kernels ? (In reply to comment #7) > this looks familiar. I think this may have been fixed in latest kernels ? I have stopped using hibernation on this laptop since my last posting here, as it was simply unreliable. I'll give it a go again and report back. Thanks for looking this way Dave. Alright, I tested hibernation again for sometime. I can admit tha what I outlined above does not happen now. I still get freezes and/or OOPSes after 3-4 cycles, just not of the same kind and reproducibility. So I guess this should be closed. Thanks to everybody who took my ticket into account and I hope it helped in improving the Linux kernel. |
Created attachment 502136 [details] INFO trace Description of problem: Sometimes while hibernating (mostly the first time after a fresh restart) I get and INFO trace, presumably while the system tries to shutdown the non-boot core of the CPU. Hibernation process completes however and the system is able to resume successfully as well afterwards. Version-Release number of selected component (if applicable): 2.6.38.6-27.fc15.x86_64.debug #1 How reproducible: Often but not every time. However, I haven't seen it happening again in subsequent hibernation/thaw cycles. If I cold-boot the system, it is bound to happen again. Steps to Reproduce: 1. Boot 2. Login 3. Hibernate gnome-shell. I have set my power button to hibernation and use this. Actual results: Trace generated. Expected results: No trace. Additional info: This is on a Dell Latitude E4300, 6GB RAM, Intel GM45 with an SP9600 CPU. This laptop seems to hang into ACPI ( "ACPI: While loop taking a really long time. loop_count=..." ) after some number of hibernation/thaw cycles and/or throw random oops traces during hibernation/thaw that I was unable to save so far. Hence I run a debug kernel and hope to catch something more in my logs just before that happens. This INFO trace is the first catch.