Bug 132547

Summary: oops when "scsi add-single-device" sent to /proc/scsi/scsi using aic79xx
Product: Red Hat Enterprise Linux 3 Reporter: Peter Levart <peter>
Component: kernelAssignee: Doug Ledford <dledford>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0CC: coughlan, petrides, riel, tao, zaitcev
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2006-0144 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-15 15:41:11 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: 168424    
Attachments:
Description Flags
OOPS dump
none
OOPS dump processed with ksymoops
none
sysreport output for the system in question none

Description Peter Levart 2004-09-14 18:16:44 UTC 
Description of problem:

When sending "scsi add-single-device" to /proc/scsi/scsi to
add a new disk on SCSI bus controlled by aic79xx driver, the
system panics.

Version-Release number of selected component (if applicable):

2.4.21-20.ELsmp (RHEL3 update 3)


How reproducible:

allways.


Steps to Reproduce:

1. issue: echo "scai add-single-device x y z w" > /proc/scsi/scsi for
new disk on the SCSI bus controlled by Adaptec aic79xx driver.


Actual results:

system panic


Expected results:

should register new scsi disk in the kernel



Additional info:

This worked with pre RHEL3 update 3 kernels, so we think it is caused
by recent fixes for bug #112426 - Dynamic adapter addition via "scsi
add-single-device". This however does not cause problems on all scsi
drivers, since we can add new devices when they are controlled by
QLogic "qla2300" driver. We only have problems when Adaptec "aic79xx"
driver is controling the disk to be registered. The oops dump shows
that "aic79xx" is in the call stack too.
Comment 1 Peter Levart 2004-09-14 18:19:48 UTC 
Created attachment 103837 [details]
OOPS dump
Comment 2 Peter Levart 2004-09-14 18:20:37 UTC 
Created attachment 103838 [details]
OOPS dump processed with ksymoops
Comment 3 Peter Levart 2004-09-14 18:22:03 UTC 
Created attachment 103839 [details]
sysreport output for the system in question
Comment 4 Ernie Petrides 2004-09-14 20:53:07 UTC 
Peter, can this problem also be reproduced on a non-tainted kernel?
Comment 5 Peter Levart 2004-09-16 06:27:02 UTC 
Yes, allways. It paniced before I installed VERITAS Foundation Suite 
too.
Comment 9 Menny Hamburger 2004-10-04 12:22:47 UTC 
I also encountered this problem using a qla2300 adapter.
While reconnecting the RAID to the HBA I got:
2004 Oct  3 16:43:23 node1 WARNING: kernel: CPU:    1
2004 Oct  3 16:43:23 node1 WARNING: kernel: EIP:    0060:
[<c021acbd>]    Tainted: GF
2004 Oct  3 16:43:23 node1 WARNING: kernel: EFLAGS: 00010286
2004 Oct  3 16:43:23 node1 WARNING: kernel:
2004 Oct  3 16:43:23 node1 WARNING: kernel: EIP is at 
scsi_release_commandblocks [kernel] 0x2c (2.4
.21-15exa/i686)
2004 Oct  3 16:43:23 node1 WARNING: kernel: eax: 00000000   ebx: 
00000000   ecx: e8f54f6c   edx: 00
000000
2004 Oct  3 16:43:23 node1 WARNING: kernel: esi: e8f54e00   edi: 
e2a33600   ebp: dd207000   esp: dd
16fec0
2004 Oct  3 16:43:23 node1 WARNING: kernel: ds: 0068   es: 0068   ss: 
0068
2004 Oct  3 16:43:23 node1 WARNING: kernel: Process utlvolumes (pid: 
28815, stackpage=dd16f000)
2004 Oct  3 16:43:23 node1 WARNING: kernel: Stack: e2a33600 e2a33600 
c697d400 00000000 c021b41e e2a
33600 dd16ff68 00000000
2004 Oct  3 16:43:23 node1 WARNING: kernel: cf2a0900 d3a55680 
dd16e000 d3a556a4 e4946cf4 c011a8c7 d
3a55680 e4946cf4
2004 Oct  3 16:43:23 node1 WARNING: kernel: b75d7d94 00000001 
f56b4500 dd16ff8c 00000001 b75d7d94 4
160100b 4160100b
2004 Oct  3 16:43:23 node1 WARNING: kernel: Call Trace:   
[<c021b41e>] proc_scsi_gen_write [kernel]
 0x44e (0xdd16fed0)
2004 Oct  3 16:43:23 node1 WARNING: kernel: [<c011a8c7>] 
do_page_fault [kernel] 0x13a (0xdd16fef4)
2004 Oct  3 16:43:23 node1 WARNING: kernel: [<c0168fe4>] locate_fd 
[kernel] 0xb9 (0xdd16ff34)
2004 Oct  3 16:43:23 node1 WARNING: kernel: [<c0158aa3>] 
get_empty_filp [kernel] 0x5b (0xdd16ff40)
2004 Oct  3 16:43:23 node1 WARNING: kernel: [<c0180409>] 
proc_file_write [kernel] 0x40 (0xdd16ff80)
2004 Oct  3 16:43:23 node1 WARNING: kernel: [<c0157ca3>] sys_write 
[kernel] 0xa3 (0xdd16ff94)
2004 Oct  3 16:43:23 node1 WARNING: kernel:
2004 Oct  3 16:43:23 node1 WARNING: kernel: Code: 89 50 04 89 02 c7 
41 04 00 00 00 00 c7 86 6c 01 0
0 00 00 00
2004 Oct  3 16:43:23 node1 WARNING: kernel:
2004 Oct  3 16:43:23 node1 EMERG: kernel: Kernel panic: Fatal 
exception
Comment 10 Doug Ledford 2005-10-17 14:46:41 UTC 

*** This bug has been marked as a duplicate of 159874 ***
Comment 11 Ernie Petrides 2005-10-17 22:28:53 UTC 
A fix for this problem was committed to the RHEL3 U7 patch pool
on 29-Sep-2005 (in kernel version 2.4.21-37.4.EL).

Propagating acks from bug 159874.
Comment 12 Red Hat Bugzilla 2006-03-15 15:41:11 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0144.html