Bug 442920
| Summary: | BUG: soft lockup - CPU#0 stuck for 61s! | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pete Zaitcev <zaitcev> | ||||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | low | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 9 | CC: | bojan, hitman1, vchelban | ||||||||||
| 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: | 2008-09-29 17:39:31 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Pete Zaitcev
2008-04-17 16:00:05 UTC
Created attachment 302761 [details]
/var/log/messages (unedited)
This looks similar to what I am seeing in my multicpu kvm guests now... so perhaps they are fine, and this is a more general problem? See https://bugzilla.redhat.com/show_bug.cgi?id=438617 In my case there's no KVM and/or Xen. Only the final trace in bug 438617 originated in an idle state, and there was no ACPI involved. I filed this one because it looked different to me. It's easier to dup bugs than to clone them anyway. davej reported what looks like the same thing in bug 444059 and there are some similar reports for F8. Can you try booting with 'processor.max_cstate=1'? Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Pete, does that have an ATI chipset by any chance ? If it's the same bug I saw, it's fixed by 'something' in .26-rc, but I've no idea which changeset, as there's so many of them, and the bug takes a while to reproduce, which makes bisecting difficult. Created attachment 308630 [details]
version, messages log and version information
I am seeing the same problem with the last kernel i386 Fedora 8. The
attachment contains my kernel information and messages log. I have had this
happen twice right after running Snort.
I've been seeing this bug for a while too, with both F8 and F9. It's certainly been there since 2.6.24, and is still present (though apparently not as bad) with the 2.6.25.4-30.fc9.x86_64 kernel. This machine (Ferrari 4000 laptop) has an ATI chipset (RS480 aka 200M). I've never been able to recreate it with any reliability (beyond "it eventually happens") but it seems to be more easily triggerable when the wireless card (p54pci) has the RFKill switch on and the 802.11+ stack trying to scan/find something in the background. Still, your note that "something fixed it in 2.6.26-rc" is encouraging. I confirm the same bug on F8 with the latest kernel. It is now happening too frequently; whenever I leave my computer idle overnight, I find it hanged in the morning with this message. Created attachment 317045 [details]
System log of a similar problem
More or less the same as already reported. Something to do with BIND (i.e. named). Note that this was just after unsuccessful attempt to create and IPSec tunnel.
Please note, the attachment from comment #10 is from an i686 machine, so this is not just x86_64 specific. Kernel is: 2.6.26.3-29.fc9.i686. Created attachment 317642 [details]
Output of lspci -vv and lspci -nn (Shuttle K45)
(In reply to comment #10) > Created an attachment (id=317045) [details] > System log of the similar problem > > More or less the same as already reported. Something to do with BIND (i.e. > named). Note that this was just after unsuccessful attempt to create and IPSec > tunnel. That is not even close to being the same problem as the original report. The original was a lockup in the timer code, while this one is a lockup in the IPsec code. (In reply to comment #7) > Created an attachment (id=308630) [details] > version, messages log and version information > > I am seeing the same problem with the last kernel i386 Fedora 8. The > attachment contains my kernel information and messages log. I have had this > happen twice right after running Snort. Also not the "same problem". This is a lockup in the wireless code. Closing this bug. Anyone still having problems should open a separate bug report and attach information about their lockup to that. |