Bug 171307
| Summary: | PowerV ipr oops | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul Nasrat <nobody+pnasrat> |
| Component: | kernel | Assignee: | Nathan Lynch <nlynch> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | davej, wtogami |
| 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: | 2006-05-05 20:28:53 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: | |||
Seeing the following warning before the oops: ipr: IBM Power RAID SCSI Device Driver version: 2.0.14 (May 2, 2005) ipr 0000:d0:01.0: Found IOA with IRQ: 325 ipr 0000:d0:01.0: Starting IOA initialization sequence. ipr 0000:d0:01.0: Adapter firmware version: 05100030 ipr 0000:d0:01.0: IOA initialized. scsi0 : IBM 573E Storage Adapter Debug: sleeping function called from invalid context at include/asm/semaphore.h:65 in_atomic():1, irqs_disabled():0 Call Trace: [c00000000fff74c0] [c000000000055684] .__might_sleep+0xf4/0x120 (unreliable) [c00000000fff7540] [c0000000001386cc] .sysfs_remove_dir+0x7c/0x250 [c00000000fff75e0] [c000000000192628] .kobject_del+0x18/0x40 [c00000000fff7670] [c000000000225dbc] .device_del+0x9c/0x100 [c00000000fff7700] [d000000000088220] .scsi_target_reap+0xe0/0x110 [scsi_mod] [c00000000fff7790] [d00000000008c230] .scsi_device_dev_release+0x1a0/0x1f0 [scsi_mod] [c00000000fff7830] [c0000000002258cc] .device_release+0x4c/0xa0 [c00000000fff78b0] [c000000000192f28] .kobject_cleanup+0x98/0x120 [c00000000fff7950] [c0000000001939a4] .kref_put+0x74/0xa0 [c00000000fff79d0] [c000000000192578] .kobject_put+0x28/0x40 [c00000000fff7a50] [c000000000225b4c] .put_device+0x1c/0x30 [c00000000fff7ad0] [d00000000007e008] .scsi_put_command+0xd8/0x120 [scsi_mod] [c00000000fff7b80] [d000000000086ba4] .scsi_next_command+0x24/0x40 [scsi_mod] [c00000000fff7c10] [d000000000086cc8] .scsi_end_request+0x108/0x170 [scsi_mod] [c00000000fff7cb0] [d000000000087018] .scsi_io_completion+0x2e8/0x570 [scsi_mod][c00000000fff7d90] [d00000000007d6e4] .scsi_finish_command+0xc4/0x130 [scsi_mod][c00000000fff7e20] [d00000000007e4c8] .scsi_softirq+0x148/0x220 [scsi_mod] [c00000000fff7ed0] [c000000000068668] .__do_softirq+0xe8/0x1c0 [c00000000fff7f90] [c000000000010728] .call_do_softirq+0x14/0x24 [c0000000027d7db0] [c00000000000bc3c] .do_softirq+0x9c/0xb0 [c0000000027d7e40] [c000000000067c34] .ksoftirqd+0x124/0x1e0 [c0000000027d7ee0] [c000000000080fd8] .kthread+0x168/0x180 [c0000000027d7f90] [c000000000010cd8] .kernel_thread+0x4c/0x68 Note - this doesn't occur with 2.6.13-1.1526_FC4 kernel on this machine. Got the same oops with 2.6.14-rc5 (with a similar __might_sleep warning as
above). Looks as if we're poking around in a scsi data structure after it's
been freed.
cpu 0x0: Vector: 300 (Data Access) at [c00000000ffff8e0]
pc: d000000000086690: .scsi_run_queue+0x30/0x240 [scsi_mod]
lr: d000000000086c78: .scsi_end_request+0x108/0x170 [scsi_mod]
sp: c00000000ffffb60
msr: 8000000000009032
dar: 6b6b6b6b6b6b6d4b
dsisr: 40000000
current = 0xc000000077f8a040
paca = 0xc000000000452400
pid = 3, comm = ksoftirqd/0
0:mon> t
[c00000000ffffc10] d000000000086c78 .scsi_end_request+0x108/0x170 [scsi_mod]
[c00000000ffffcb0] d000000000086fc8 .scsi_io_completion+0x2e8/0x570 [scsi_mod]
[c00000000ffffd90] d00000000007d6e4 .scsi_finish_command+0xc4/0x130 [scsi_mod]
[c00000000ffffe20] d00000000007e4c8 .scsi_softirq+0x148/0x220 [scsi_mod]
[c00000000ffffed0] c000000000067bc8 .__do_softirq+0xe8/0x1c0
[c00000000fffff90] c0000000000106c8 .call_do_softirq+0x14/0x24
[c00000000ffa3db0] c00000000000bc1c .do_softirq+0x9c/0xb0
[c00000000ffa3e40] c0000000000672f4 .ksoftirqd+0x124/0x1e0
[c00000000ffa3ee0] c00000000007fe38 .kthread+0x168/0x180
[c00000000ffa3f90] c000000000010c78 .kernel_thread+0x4c/0x68
There was at least one similar sounding bug fixed upstream recently. Does the latest rawhide kernel have the same issue ? Closing due to lack of response. |
Description of problem: Loading the ipr driver on squad5-lp1 failed: Version-Release number of selected component (if applicable): kernel-2.6.13-1.1617_FC5.ppc64.rpm How reproducible: Always Steps to Reproduce: 1. boot network:, 2. rawhide nostorage 3. I used the tree on my laptop Actual results: cpu 0x1: Vector: 300 (Data Access) at [c00000000fff78e0] | | pc: d0000000001e06e0: .scsi_run_queue+0x30/0x240 [scsi_mod] lr: d0000000001e0cc8: .scsi_end_request+0x108/0x170 [scsi_mod] sp: c00000000fff7b60 msr: 8000000000009032 dar: 1e0 dsisr: 40000000 current = 0xc000000002ab3820 paca = 0xc00000000046ec00 pid = 6, comm = ksoftirqd/1 enter ? for help 1:mon> t<Alt-Tab> between elements | <Space> selects | <F12> next screen [c00000000fff7c10] d0000000001e0cc8 .scsi_end_request+0x108/0x170 [scsi_mod] [c00000000fff7cb0] d0000000001e1018 .scsi_io_completion+0x2e8/0x570 [scsi_mod] [c00000000fff7d90] d0000000001d76e4 .scsi_finish_command+0xc4/0x130 [scsi_mod] [c00000000fff7e20] d0000000001d84c8 .scsi_softirq+0x148/0x220 [scsi_mod] [c00000000fff7ed0] c000000000068668 .__do_softirq+0xe8/0x1c0 [c00000000fff7f90] c000000000010728 .call_do_softirq+0x14/0x24 [c00000000ff93db0] c00000000000bc3c .do_softirq+0x9c/0xb0 [c00000000ff93e40] c000000000067c34 .ksoftirqd+0x124/0x1e0 [c00000000ff93ee0] c000000000080fd8 .kthread+0x168/0x180 [c00000000ff93f90] c000000000010cd8 .kernel_thread+0x4c/0x68 1:mon> ? Expected results: Worked. Additional info: