Bug 155074
| Summary: | hotplug gets stuck. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Jones <davej> |
| Component: | hotplug | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | CC: | pfrields, rvokal, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-03 23:06:35 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: | |||
killing these processes brings back a speedy desktop. The calls to swapon still occur though. Wieeeerd. false alarm on the sys_swapon -- wrong System.map in use. (its slab debug :-) Why hotplug went nuts is still a mystery though. I'd love to know what that ioctl was..... if you can reproduce it, what files do they have open? You still seeing this? (Woo, I get to do this this time. :) ) nope, only ever happened once. *shrug* rawhide oddness of the day I suppose. |
I did an upgrade of an FC3 to rawhide, and on logging in, found that everything was really sluggish. Firing up top showed that the CPUs were both at 100% ! These two.. 3811 root 20 -5 5268 404 328 R 92.3 0.0 24:03.47 05-pam_console. 3997 root 20 -5 5268 404 328 R 90.6 0.0 23:19.10 default.hotplug Take it in turns to be scheduled, and do.. bugger all. strace of those processes shows no output whatsoever. sysrq-t shows.. 05-pam_consol R running task 0 3811 7552 (NOTLB) bash S ffff81002e4e0170 0 7571 4634 7620 7768 7449 (NOTLB) ffff81006fea3eb8 0000000000000086 ffff81002e4e0170 0000000000000002 ffffffff80543720 0000000000000239 00000074000001e3 ffff81002e4e0380 ffff81002e4e0170 ffff81002e1770f0 Call Trace:<ffffffff8013d51e>{do_wait+2798} <ffffffff80134440>{default_wake_function+0} <ffffffff8019d59c>{sys_ioctl+108} <ffffffff8010ea72>{system_call+126} default.hotpl R running task 0 3997 7674 (NOTLB) bash S ffff81002d6ad880 0 7768 4634 7813 7571 (NOTLB) ffff81002de2beb8 0000000000000082 ffff81002d6ad880 0000000000000002 ffffffff80543720 00000000000000f3 00000074000001e3 ffff81002d6ada90 ffff81002d6ad880 ffff8100302a00f0 Call Trace:<ffffffff8013d51e>{do_wait+2798} <ffffffff80134440>{default_wake_function+0} <ffffffff8019d59c>{sys_ioctl+108} <ffffffff8010ea72>{system_call+126} What they're waiting for is a mystery to me. more oddness.. something is calling sys_swapon once a second. in 30 mins of uptime, its been called over 10,000 times.