Bug 230322
| Summary: | Soft lockup on SMP machine on insertion of USB memory sticks | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 6 | CC: | wtogami | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 2.6.19-1.2911.6.4.fc6 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-03-05 10:59:21 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 230628 | ||||||||
| Attachments: |
|
||||||||
|
Description
Jonathan Underwood
2007-02-28 10:37:33 UTC
Created attachment 148903 [details]
Output of lspci -vv
Created attachment 148904 [details]
output of lsusb -vv with usb stick inserted
I should also add that I've seen this bug with kernels back as far as kernel.x86_64 2.6.18-1.2869.fc6 I should also add that booting with noapic doesn't fix the problem, and the machine doesn't manage to boot with the nolapic option. I officially hate the unwinder. What a useless pile of garbage. So now there's no telling where the either of CPUs got stuck... I wanted to take this bug, but I'm not even sure that usb-storage is actually a culprit. BTW, what does happen if you boot with libusual.bias="ub" in grub.conf? Hi Pete, thanks for your response. Adding libusual.bias="ub" fixes the problem,
once I had disabled SElinux. I'm not sure that the problem is specific to the
usb-storeage layer though, as I am also seeing soft lockups when vmware tries to
create its virtual ethernet interfaces. These also disappear with
libusual.bias="ub"
[Just to put your mind at rest though - the problem originally reported in this
bug is present with an untainted kernel (i.e. without the vmware module loaded).]
As an aside, if there are any plans to enable libusual.bias="ub" out of the box,
then I guess the SElinux issue will need fixing up. The SElinux messages
displayed are:
audit(1172746861.823:7): avc: denied { read } for pid=5340
comm="hald-probe-volu" name="uba1" dev=tmpfs ino=20335
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:device_t:s0
tclass=blk_file
audit(1172746861.824:8): avc: denied { ioctl } for pid=5340
comm="hald-probe-volu" name="uba1" dev=tmpfs ino=20335
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:device_t:s0
tclass=blk_file
SELinux: initialized (dev uba1, type vfat), uses genfs_contexts
audit(1172746862.109:9): avc: denied { getattr } for pid=4470 comm="hald"
name="uba1" dev=tmpfs ino=20335 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=blk_file
Thanks for the testing, Jonathan. I'll clone this bug for Dan Walsh regarding the SElinux issue. But ub is a workaround. The usb-storage is the official driver, so I'll need to fix that. There's also a bug 226742 where the requestor managed to capture a useable trace without unwinder. I'll work under assumption that these two are the same, and we'll take it from there. Hi Pete, I'm happy to report that this bug has vanished with the latest kernel (2.6.19-1.2911.6.4.fc6), and so I'll close the bug accordingly. |